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Foreword 


Under  the  sponsorship  of  the  Air  Force  MateriaJ  Command  (AFMC)  Robotics  and  Automation 
Center  of  Excellence  (RACE)  at  Kelly  Air  Force  Base,  San  Antonio,  TX,  the  Unified  Teler- 
obotic  Architecture  Project  was  funded  to  define  an  open  architecture  to  improve  the  efficiency 
and  productivity  of  the  maintenance  operations.  The  UTAP  specifies  an  open  architecture  for 
telerobotics  along  with  specific  implementation  options  designed  to  assist  the  work  at  Air  Force 
maintenance  facilities. 

The  status  of  the  UTAP  Standard  Interface  Environment  - SIE  - has  progressed  to  the  point 
that  the  architecture  remains  stable  and  the  project  has  seen  the  interfaces  evolve  significantly 
after  several  Design  Reviews.  To  date,  the  emphasis  of  review  effort  has  been  on  the  remote 
interfaces  containing  the  real-time  control  elements.  Additional  work  remains  to  validate  the 
functionality  of  the  interfaces,  resolve  configuration  and  integration  issues,  solidify  the  interface 
environment  and  substantiate  the  validation  and  conformance  process. 


Disclaimer 

No  approval  or  endorsement  of  any  commercial  product  by  the  National  Institute  of  Standards 
and  Technology  is  intended  or  implied. 

Any  software  source  code  contained  herein  was  produced  in  part  by  the  National  Institute  of 
Standards  and  Technology  (NIST),  an  agency  of  the  U.S.  government,  and  by  statute  is  not 
subject  to  copyright  in  the  United  States.  Recipients  of  this  software  assume  aR  responsibility 
associated  with  its  operation,  modification,  maintenance,  and  subsequent  redistribution. 


Electronic  Access  to  Document 

A compressed  copy  of  this  document  in  Postscript  format  and  the  related  source  code  in 
shar  format  is  available  electronically.  Access  to  the  UTAP  report  and  UTAP  source  code 
is  available  through  the  Internet  standard  File  Transfer  Protocol  (ftp)  . The  ftp  site  name 
is  “giskard.cme.nist.gov”.  Directions  for  an  ftp  session  to  retrieve  the  report  and  source  code 
follow. 

First,  change  directory  to  your  local  destination  directory.  Next  use  the  command  “ftp”  to 
remotely  login  using  “anonymous”  for  the  name,  and  give  your  email  address  for  the  password. 
This  will  aRow  you  reading  and  copying  privUeges. 

you[l]X  cd  your_local_directory 
you[2]%  ftp  giskard.cme.ni8t.gov 
Connected  to  giskard.cme.nist.gov. 

220  giskard  FTP  server  (Version  bu-2.3(1)  Wed  Apr  6 14:21:22  EOT  1994)  ready, 
lame  (giskard. erne. nist. gov : youmame ) : anonymous 

331  Guest  login  ok,  send  your  complete  e-mail  address  as  passuord. 

PassHord:  "your  complete  e-mail  address" 

230-  Welcome  to  the  FTP  server  for  the  Intelligent  Systems  Division 

230-  lational  Institute  of  Standards  and  Technology 

230-  Gaithersburg,  HD 

230- 

230-Please  read  the  file  README 

230-  it  uas  last  modified  on  Hon  Dec  6 11:57:23  1993  - 136  days  ago 
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230  Guest  login  ok,  access  restrictions  apply. 


Once  connected,  change  into  the  “utap”  directory  containing  the  desired  files. 

ftp>  cd  pub/utap 

250  CWD  command  successful . 

To  get  everything  at  once,  a compressed  tar  version  of  the  documentation  and  a shar  bundle  of  the 
source  files  is  in  the  main  directory.  ALWAYS  USE  BINARY/IMAGE  MODE  TO  TRANSFER 
THESE  FILES!  Text  mode  does  not  work  for  tar  files  or  compressed  files. 

ftp>  mget  utap. doc. tar. Z utap . src . shar 

Terminate  the  ftp  session  with  the  quit  command. 

ftp>  quit 

Assuming  a UNIX  environment,  one  wiU  be  required  to  unbundle  the  files.  For  the  documenta- 
tion, uncompress  and  extract  the  documentation  files  with  tar.  The  source  is  in  shar  format,  so 
use  unshar  to  unbundle  files. 

you[l]y,  (mkdir  doc;  cp  utap. doc. Z doc;  cd  doc;  \ 

uncompress  utap.doc.tar .Z;  tar  -xf  utap. doc. tar;  ) 

you[2]%  (mkdir  src;  cp  utap. src .shar  src;  cd  src;  \ 
unshar  utap . src .shar ; ) 

The  documentation  is  in  Postscript  format  (*.ps). 


Introduction 

This  introduction  is  not  considered  part  of  the  proposed  standard. 

The  purpose  of  this  Working  Draft  Standard  Document  is  to  define  a common  architecture  for 
telerobotics  systems  for  use  in  Air  Force  applications  with  great  duaJ-use  potential  for  civilian 
applications.  There  are  various  Air  Force  applications,  such  as  paint  stripping  and  painting, 
surface  finishing,  and  skin  cutting  which  can  benefit  from  the  integration  of  telerobotics  systems 
tools. 

Telerobotics  systems  wiU  enable  human  operators,  who  now  execute  these  tasks  manuaUy,  to 
operate  telerobots  to  execute  the  tasks  faster,  safer,  and  with  higher  quality.  Telerobotics  aims 
at  the  integration  and  fusion  of  the  strengths  of  machine  and  human  to  extend  the  capabiUties 
of  either.  Telerobotics  transcends  the  human  barriers  of  space,  time,  power,  speed,  accuracy, 
and  safety  as  weU  as  the  machine  barriers  of  cognition,  understanding,  reasoning,  and  planning. 
Besides  the  conventional  applications  of  telerobotics  technology  to  space,  underwater,  nuclear, 
and  mining  operations,  telerobotics  technology  may  be  appUed  to  the  semi- automation  of  in- 
dustrial processes  where  the  fuU  robotic  automation  is  difficult  to  implement  but  the  manual 
operation  is  too  costly  to  practice.  The  Air  Force  appUcation  domains  of  aircraft  maintenance 
and  remanufacturing  are  good  candidates  for  successful  telerobotics  insertion  due  to  their  smaU 
batch  sizes,  partiaUy  modeled  task  environment,  and  physicaUy  chaUenging  and  hazardous  work 
environments.  In  aircraft  maintenance  and  remanufacturing  appUcations  the  operator  may  pro- 
vide the  high  level  cognitive  planning  and  sensory  perception,  which  are  currently  difficult  to 
provide  in  a robotic  system,  while  the  robot  provides  precise  control  and  works  in  dangerous 
environments. 
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It  is  intended  that  commercial  telerobotics  applications  will  become  feasible  due  to  the  speci- 
fication of  an  architecture  and  standardizing  the  components  of  the  systems.  This  will  allow 
systems  to  be  built  from  standard  hardware  and  software  modules  which,  rather  than  being  cus- 
tom developed,  can  be  reused  from  other  applications  or  purchased.  The  architecture  therefore 
provides  a framework  for  design  and  implementation  of  telerobotics  systems  for  different  teler- 
obotics applications  while  utilizing  a common  architecture  and  hardware  and  software  modules. 
The  customization  in  developing  a system  will  be  in  the  selection  of  which  modules  to  use  rather 
than  in  development  of  all  the  modules.  This  wiU  allow  both  minimal,  i.e.,  inexpensive,  and 
complex,  i.e.,  expensive  systems  to  be  built  using  the  same  architecture. 

Maintenance  of  systems  developed  with  standard  modules  will  likely  be  less  expensive  and  cause 
less  system  down  time  than  for  custom  systems.  Service  personnel  will  be  easier  to  find  since 
their  skills  will  have  wider  applicability  than  those  of  people  who  are  famihar  with  a custom 
system. 

An  important  feature  of  the  architecture  from  the  operator’s  viewpoint  is  a common  operator 
interface  across  different  applications.  The  various  application  interfaces  will  be  easier  to  learn, 
remember,  and  use.  This  will  reduce  training  time  and  costs,  as  well  as  provide  more  skillful 
and  reliable  operators. 

Audience 

The  intended  audience  that  this  Working  Draft  Standard  Document  has  been  developed  for: 

a)  Air  Force  Maintenance  System  Designers 

b)  Control  System  Designers/Engineers 

c)  Control  System  Integrators 

d)  Telerobotic  Control  Applications  Programmers 

e)  Hardware  and  Software  Purchases 

f)  End-users  operating  a SIE  controller 

Organization  of  the  Working  Draft  Document 

The  Working  Draft  Standard  Document  is  divided  into  9 parts. 

- Scope 

- References 

- Definitions  and  global  concepts 

- Conformance 

- Architecture  Reference  Model 
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— Interface  Environment 

— Information  Models 

— Configuration  and  Integration 

— Interface  Framework 

A series  of  annexes  follow  the  Working  Draft  Standard  Documentthat  contain  normative  and 
informative  reference  material. 


Background 

The  UTAP  architecture  definition  utilized  telerobotics  research  and  development  results  from 
universities  and  national  laboratories,  previous  studies,  and  current  robotics  off-the-shelf  capa- 
bilities. Most  of  the  required  capabilities  have  been  demonstrated  in  prototype  systems,  but 
without  a common  architecture  approach.  The  unified  architecture  specifies  the  hardware  and 
software  modules  so  that  telerobotics  systems  can  be  built  from  standard  commercial  compo- 
nents. 

The  architecture  described  in  this  report  is  a refinement  of  the  architecture  described  in  an  earlier 
study  [JPL].  That  study  provided  a high  level  description  of  the  unified  architecture  and  its 
components.  The  unified  architecture  is  an  integration  of  many  open  architecture  technologies. 

At  NIST,  the  unifying  architecture  for  system  development  has  been  the  Real-time  Control 
System  (RCS)  [RCS]  that  has  evolved  from  cerebral  models  of  brain  behavior  into  a general 
theory  of  intelligence.  In  addition  to  the  RCS  architecture,  a methodology  accompanies  the 
architecture  for  the  analysis,  design  and  implementation  of  control  systems.  The  importance  of 
the  RCS  lies  in  the  abstractions  and  generalizations  it  forwards  in  pursuit  of  open  solutions  that 
apply  beyond  the  demands  of  any  one  application. 

Another  related  architecture  is  the  architecture  associated  with  the  Next  Generation  Controller 
(NGC)  project  [SOSAS].  It  is  intended  that  this  UTAP  architecture  be  an  Application  Archi- 
tecture for  an  NGC  system.  The  modules  of  the  system  are  therefore  described  as  components 
of  an  NGC  system  with  specified  responsibilities  and  interfaces.  A specific  NGC  profile  is  not 
specified  since  that  would  be  selected  for  a specific  Application  System. 


Purpose 

Several  principles  guided  the  development  of  this  Working  Draft  Standard  Document. 

Open  Architecture  Technology: 

Openness  provides  benefits  and  savings  through  flexibility  and  extensibility  but  does  not  ad- 
dress portability.  Interfaces  under  one  vendor’s  open  architecture  generally  wiU  not  run  under 
another  vendor’s  system.  Openness  is  the  first  step  towards  standardization.  Requirements 
for  a standard  “open  solution”  include  the  ability  to  allow  the  development  of  controllers 
by  users  or  system  integrators  who  want  to  piece  together  their  own  systems  component  by 
component,  modify  the  way  their  controller  does  certain  things,  apply  their  modifications  to 
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another  controller,  or  start  small  and  upgrade  as  they  grow.  These  basic  open  architecture 
requirements  include: 

Modularity:  Refers  to  the  ability  of  controls  users  and  system  integrators  to  purchase 
and  replace  components  of  the  controller  without  unduly  affecting  the  rest  of  the  con- 
troller. 

Extensibility:  Refers  to  the  ability  of  intelligent  users  and  third  parties  to  incrementally 
add  functionality  to  a module  without  replacing  it  completely. 

Portability:  Refers  to  the  ease  with  which  a module  can  run  across  platforms  Standards 
such  as  ANSI  C and  POSIX  are  required  to  serve  as  a reference  to  which  programmers 
adhere. 

Scalability:  Like  portability,  refers  to  the  ease  with  which  a module  can  be  made  to 
run  in  a controller  based  on  another  platform,  but  unlike  portability,  scalability  allows 
different  performance  based  on  the  platform  selection.  Scalability  means  that  a controller 
may  be  implemented  as  easily  by  systems  integrators  on  a high-speed  processor,  as  a 
distributed  multi-processor  system,  or  on  a standalone  PC. 

Applying  Today’s  Technology: 

The  UTAP  is  intended  as  a SIE  for  immediate  use.  One  could  overestimate  the  real-potential 
of  systems  in  developing  the  scenarios,  and  become  mired  in  the  range  of  possibilities  and 
expectations  of  an  architecture.  For  the  UTAP  architecture  and  interfaces,  it  is  assumed  that 
a reasonable  level  of  effort  and  Commercial  Off  The  Shelf  (COTS)  equipment  are  immediately 
available  and  can  be  used  to  solve  the  apphcations  tasks. 

Another  assumption  was  that  innovation  would  be  minimized.  Innovation  affects  both  the 
“how-to”  and  “what  is  in”  when  defining  interfaces.  For  the  how-to,  should  the  interfaces 
use  established,  but  sometimes  flawed,  approaches,  or  should  the  interface  adapt  newer  but 
evolving  and  unproven  approaches?  There  are  established  efforts  for  interface  definitions  that 
are  very  elegant  (e.g.,  [STEP],  [CORBA]),  but  are  either  not  cost-effective  or  still  suffering 
growing  pains.  The  UTAP  will  start  with  a baseline  of  a simple  strategy  and  concentrate  on 
the  “what  is  in”  the  interfaces  instead  of  dwelling  on  the  “how-to”  pass  information  within 
an  interface.  It  will  be  assumed  that  at  some  point  an  industry-standard  for  manufacturing- 
based  application  interface  communication  and  infrastructure  will  have  evolved. 

Another  question  is  the  amount  of  scientific  pioneering  of  new  technology  expected  within  the 
interfaces,  e.g.,  “What  are  the  functions  that  should  be  incorporated  into  the  next  generation 
of  commercially  available  sensors?”  For  instance,  should  an  array  sensor  - such  as  a range 
sensor  - return  curvature  identification?  For  the  UTAP  interfaces,  we  did  not  attempt  to 
innovate  new  definitions,  but  rather,  attempted  to  standardize  on  established  technology. 
However,  the  level  of  innovation  within  an  interface  is  not  compromising  since  the  UTAP 
modules  and  interfaces  are  scalable. 
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Focus  on  Interface  Content,  Not  Interface  Transport: 

An  interface  has  two  critical  issues.  One  issue  is  the  method,  or  “How-to-pass,”  which 
describes  how  one  will  represent  the  language  and  the  perform  the  communication.  The 
other  issue  is  interface  knowledge  or  the  “What-to-pass”  within  the  interface.  The  interface 
knowledge  is  tied  to  the  application  requirements  and  must  match  the  needs  for  the  command, 
control,  status  and  synchronization  of  the  system.  The  “How-to-pass”  issue  is  guaranteed 
to  wrap  one  around  the  axle.  Obviously,  one  cannot  be  blind  to  the  how-to-pass  elements 
of  the  interface  - protocols,  configuration  and  language  style  greatly  impact  the  Interface 
Framework. 


Test  Validation 

The  first  validating  implementation  of  the  architecture  will  be  done  using  a commercial  con- 
troller. The  hierarchy  of  components  associated  with  major  commercial  robotics  systems  for 
robot  control  is  shown  in  figure  1.  Higher  level  components  are  supported  by  lower  level  com- 
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Figure  1 - Commercial  robotics  components  hierarchy 
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ponents.  The  Servo  Control  component  provides  servo  control  of  the  joint  angles.  It  has  joint 
angle  commands  for  inputs.  The  Inverse  Kinematics  component  transforms  task  level  commands 
into  joint  commands,  e.g.,  pose  of  the  tool  into  joint  angles  which  result  in  that  tool  pose.  The 
Controller  provides  the  task  level  control  including  merging  Cartesian  trajectories  with  task 
level  sensor  based  control.  The  Trajectory  Planner  generates  the  planned  trajectory,  e.g.,  us- 
ing a trajectory  generator  to  generate  Cartesian  setpoints  for  the  tool  to  pass  through.  The 
Interpreter  interprets  and  sequences  the  task  program  commands.  The  Translator  translates 
language  source  commands  into  intermediate  p-code  commands  which  are  more  efficient  to  exe- 
cute than  the  language  commands.  The  Language  is  a general  purpose  robotics  task  description 
language  which  provides  all  capability  needed  to  support  the  desired  appHcations.  The  Tools 
are  software  packages  specific  to  application  domains  which  provide  macro  commands  which  can 
be  used  to  efficiently  develop  application  programs.  The  Tools  may  also  provide  an  environment 
for  developing  application  programs.  The  Application  is  the  application  program  for  a specific 
application.  It  will  be  developed  with  commands  from  the  Tools  package(s)  and  the  supporting 
language.  Ideally,  the  application  program  will  be  developed  using  only  the  Tools  packages  and 
Tools  supporting  development  environment.  Another  way  to  envision  this  hierarchy  of  com- 
ponents is  by  combining  components  into  components  which  are  commonly  separate  parts  of  a 
robotic  system,  as  shown  in  figure  2.  The  controller  is  the  robot  controller,  e.g.,  Fanuc,  Adept,  or 


Trellis.  The  language  is  the  robot  language,  e.g.,  Karel,  SIL  or  V-|-.  The  Tools  and  Applications 
are  the  same  as  the  Tools  and  Applications  above. 


Conformance 

In  publishing  this  Working  Draft  Standard  Document,  the  Working  Group  intends  to  provide  a 
yardstick  against  which  various  control  implementations  can  be  measured  for  conformance.  It 
is  not  the  intent  of  the  Working  Group  to  measure  or  rate  any  products,  or  reward  or  sanction 
any  vendors  of  products  for  conformance  or  lack  of  conformance  to  this  standard,  nor  will  any 
attempt  to  enforce  this  standard  by  these  or  any  means. 
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It  will  be  assumed  that  individuals  who  are  evaluating  the  product  will  be  able  to  attach  and 
run  a test  and  verification  harness  for  a particular  module.  An  entire  controller  would  be  tested 
and  verified  for  conformance  through  the  process  of  harness  rewiring  to  accept  one,  two,  ...  n 
modules. 


Extensions 

Activities  to  extend  this  Working  Draft  Standard  Documentfor  additional  requirements  are 
anticipated.  This  is  an  overview  of  how  extensions  to  the  standard  will  be  done  and  how  users 
of  the  standard  can  keep  track  of  that  status. 

Extensions  are  provided  as  Supplements  to  this  document.  Supplements  may  contain  either 
required  functions  or  optional  facilities.  Supplements  may  add  additional  conformance  require- 
ments defining  new  classes  of  conforming  systems  or  applications. 

Supplements  are  not  used  to  provide  a general  update  of  the  standard.  Standard  revisions  are 
done  through  the  review  procedure  as  specified  by  the  standard  body.  Supplements  currently 
under  consideration  at  this  time  include: 

- CORE  A Interface 

— IDL  or  ASN.l  Interface  Definitions 


Typographic  Conventions 

This  Working  Draft  Standard  Document  uses  the  following  typographic  conventions: 

a)  The  italic  font  is  used  for  the  initial  appearance  of  defined  terms;  and  cross  references 
to  defined  terms  within  the  definitions  terminology. 

b)  The  bold  font  is  used  for  C and  C-f+  language  types;  references  to  other  sections  or 
chapters. 

c)  The  constant-width  font  is  used  to  illustrate  examples  of  code. 


Related  Standard  Work 

This  Working  Draft  Standard  Document  was  prepared  by  a Working  Group  under  the  leader- 
ship of  the  RACE  with  the  intention  to  standardize  this  effort  within  a Technical  Standards 
Committee.  At  the  time  this  working  draft  was  distributed,  the  membership  of  the  Working 
Group  was  as  follows: 

Working  Group 

Paul  G.  Backes  John  L.  Michaloski  Robert  Steele 

Michael  Leahy  Scott  Petrosky  Albert  Wavering 

Sukan  Lee  Francois  Pin  Thomas  Wheatley 

Ronald  Lumia 
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Unified  Telerobotic  Architecture  Project 
Standard  Interface  Environment  — 
Working  Draft  Document 


1 Scope 


This  Working  Draft  Standard  Documentis  intended  to  serve  as  a guide  in  the  system  design 
and  implementation  of  telerobotic  systems,  to  minimize  the  variety  of  system  interfaces  and  to 
promote  a unified  approach  to  building  telerobotic  systems  and  to  foster  the  interchangeability 
of  telebrobotic  architecture  components.  It  is  intended  to  provide  scalable  complexity  to  ac- 
commodate simple  systems  and  at  the  same  time  be  systematically  extensible  to  accommodate 
more  complex  systems. 

The  standard  presents  a reference  model  architecture  and  SIE  for  telerobotic  applications.  The 
standard  contains  general-purpose  concepts  and  presents  terminology  definitions  for  the  archi- 
tecture and  the  interface  between  components. 


2 References 


[JPL]  NASA  JPL,  “A  Generic  Telerobotics  Architecture  for  C-5  Industrial  Processes,”  Final 
Report  Prepared  for  Air  Force  Material  Command  (AFMC),  Robotics  and  Automation  Center 
of  Excellence  (RACE),  San  Antonio  Air  Logistics  Center,  Kelly  AFT,  TX  78241. 

[ASN.la]  Information  Processing  - Open  Systems  Interconnection  - Abstract  Syntax  Notation 
One  (ASN.l);  International  Organization  for  Standardization  and  International  Electrotechnical 
Committee,  1987,  International  Standard  8824. 

[ASN.lb]  Information  Processing  - Open  Systems  Interconnection  - Abstract  Syntax  Nota- 
tion One  (ASN.l)  - Draft  Addendum  1:  Extensions  to  ASN.l;  International  Organization  for 
Standardization  and  International  Electrotechnical  Committee,  1987,  International  Standard 
8824/DAD  1. 

[CORBA]  Object  Management  Group.  Object  Management  Architecture  Guide,  Document 
92.11.1,  Framingham,  MA,  1991. 


[EIA274]  “EIA  Standard  - EIA-274-D,  Interchangeable  Variable,  Block  Data  Format  for  Posi- 
tioning, Contouring,  and  Contouring/Positioning  Numerically  Controlled  Machines,”  Engineer- 
ing Industries  Association,  Washington,  D.C.,  February  1979. 
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[EIA441]  “EIA  Standard  - EIA-441,  Operator  Interface  Functions  of  Numerical  Controls,”  En- 
gineering Industries  Association,  Washington,  D.C.,  January  1979. 

[MMSl]  ANSI/EIA-511  part  1,  1989  - Manufacturing  Message  Specification  (MMS)  - Service 
Definition. 

[MMS2]  ANSI/EIA-511  part  2,  1989  - Manufacturing  Message  Specification  (MMS)  - Protocol 
Definition. 

[MMS  1924]  ANSI/EIA  Standard  Proposal  No.  1924  - A Proposed  New  Companion  Standard 
to  EIA-511,  “Numerical  Control  Message  Specification,”  (if  approved,  to  be  published  as  ANSl- 
19506-4/EIA-566). 

[OSI]  “Open  Systems  Interconnection:  definition  of  common  application  service  elements,”  In- 
ternational Standards  Organization. 

[POSIX]  “POSIX  (Portable  Operating  System  Interface),  ANSI/IEEE  Std  1003.1-1988”  or 
FIPS-PUB-151-1. 

[RS441]  “EIA  Standard  441,  Operator  Interface  Functions  of  Numerical  Controls,”  Electronics 
Industries  Association,  Washington,  D.C.,  January  1979  (Reaffirmed. July  14,  1992). 

[RS274D]  “EIA  Standard  - EIA-274-D,  Interchangeable  Variable,  Block  Data  Format  for  Posi- 
tioning, Contouring,  and  Contouring/ Positioning  Numerically  Controlled  Machines,”  Engineer- 
ing Industries  Association,  Washington,  D.C.,  February,  1979. 

[STEP41]  “ISO  10303-41  Industrial  Automation  Systems  and  Integration  Product  Data  Repre- 
sentation and  Exchange  - Part  41:  Integrated  Resources:  Fundamentals  of  Product  Description 
and  Support.” 

[STEP42]  “ISO  10303-42  Industrial  Automation  Systems  and  Integration  Product  Data  Repre- 
sentation and  Exchange  - Part  42:  Integrated  Resources:  Geometric  and  Topological  Represen- 
tation.” 

[SOSAS]  National  Center  for  Manufacturing  Sciences,  “Next  Generation  (NGC)  Specification 
for  an  Open  System  Architecture  Standard  (SOSAS),  Revision  2.5”,  August  1994. 


3 Definitions 


3.1  Standards  Terminology 

3.1.1  defined:  A value  or  behavior  is  defined  if  the  implementation  defines  and  documents  the 
requirements  for  correct  program  construct  and  correct  data. 
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3.1.2  may:  With  respect  to  conformance,  the  word  may  is  to  be  interpreted  as  an  optional 
feature  that  is  not  required  in  this  standard  but  can  be  provided. 

3.1.3  shall:  With  respect  to  conformance,  the  word  shall  is  to  interpreted  as  a requirement  on 
the  implementation  for  strict  conformance. 

3.1.4  should:  With  respect  to  conformance,  the  word  should  is  to  interpreted  as  not  a strict 
requirement,  but  interpreted  as  a necessary  courtesy  for  explaining  non-standard  additions  and 
extensions. 

3.1.5  supported:  Certain  functionality  in  this  standard  is  optional,  but  the  interfaces  to  that 
functionality  are  always  required.  If  the  functionality  is  supported,  the  interfaces  work  as  specified 
by  this  standard  (except  that  they  do  not  return  the  error  condition  indicated  for  not-supported 
case).  If  the  functionality  is  not  supported,  the  interface  shall  always  return  the  indication 
specified  for  this  situation. 

3.1.6  undefined:  A value  or  behavior  is  undefined  ii  the  standard  imposes  no  portability  and 
interoperability  requirements  on  applications  for  erroneous  program  construct,  erroneous  data, 
or  use  of  an  indeterminate  value.  Implementations  (or  other  standards)  may  specify  the  result 
of  using  that  value  or  causing  that  behavior. 

3.1.7  unspecified:  A value  or  behavior  is  unspecified  if  the  standard  imposes  no  portability 
requirements  on  applications  for  correct  program  construct  , correct  program  data,  or  correct 
program  interoperability. 


3.2  General  Terms 

3.2.8  API:  The  term  API  refers  to  a type  of  interface  in  which  one  has  a data  representation 
and  set  of  functions  associated  with  the  data  representation.  By  contrast  for  example.  Postscript 
is  an  interface  language  for  printers.  For  an  API,  the  data  and  function  abstraction  (in  Smalltalk 
00  lingo,  class  and  methods)  hides  the  underlying  physical  representation  or  implementation 
from  the  programmer.  As  an  example,  C is  a general-purpose  language  (CPU  interface)  which 
contains  many  application-specific  API  libraries,  such  as  math,  or  a socket  library  as  an  API 
abstraction  for  TCP/IP  communication.  For  the  math  library,  one  has  a representation  of  the 
data  (a  double  in  IEEE  floating  point,  a set  of  functions  (e.g.,  sin,  cos,  atan,  etc.)  which  hide 
whether  the  computation  is  done  on  FPU  hardware  or  in  software. 

The  environment  is  important  in  specifying  options.  Through  the  use  of  compiler  switches  one 
can  specify  an  platform  environment  for  a FPU  or  not. 

3.2.9  build:  An  open-architecture  controller  is  built  from  modules  and  component  parts.  The 
operation  to  build  a controller  from  module  components  is  multi-faceted  and  includes  the  fol- 
lowing: 


- User  defines  “initial  conditions”  such  as  hardware,  peripherals,  (i.e.,  computing  resources 
in  general) 
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— Platform  supplies  system  low-level  services  (e.g.,  file-mgmt,  etc.) 

— Integrator  wires  selected  modules  together 

— Modules  need  to  support  user-specification  of  timing  requirements 

— Supply  of  “dummy”  or  minimal  modules  where  user  has  not  selected  any 

— Desirability  to  have  convenient  ways  to  experiment;  reconfigure  modules  quickly  and 
(not  required)  capture  their  results  in  order  to  organize  your  experimentation 

3.2.10  channel:  A channel  (or  transport)  is  the  abstract  connection  between  communicating 
modules  along  which  the  message  is  transferred,  e.g.  network,  shared  memory,  local  procedure 
caU,  remote  procedure  caU,  software  interrupt,  event,  signal,  network,  stream,  mailbox,  etc. 

3.2.11  connection:  A connection  requires  two  (or  more)  processes  to  communicate  via  a con- 
nection. One  module  is  the  sender  (or  writer)  and  one  (or  more)  module  is  the  receiver  (or 
reader).  A good  analogy  to  this  paradigm  is  a telephone  conversation.  When  you  initiate  a 
telephone  call,  you  are  initiating  a connection.  The  other  party  hears  the  telephone  ring,  and 
then  answers  the  phone  to  complete  the  connection.  How  the  connection  is  actually  made  is  the 
responsibility  of  the  lower-layer  service  (the  telephone  companies  handle  the  underlying  hard- 
ware and  communication  protocol).  The  conversation  consisting  of  an  agreed  upon  language  and 
dialogue  protocol  is  equivalent  to  the  application  session  layer  or  Open  System  Interconnection 
(OSI)  [OSI]  layer  7. 

3.2.12  component:  A component  definition  will  adopt  the  NGC  SOSAS  [SOSAS]  concept 
of  a reference  architecture  consisting  of  primitive  and  aggregate  components.  Components  are 
defined  as  abstract  building  block  elements  that  describe  functionality  and  communication. 
The  application  architecture  is  built  from  these  components.  Components  have  the  following 
attributes: 

— responsibility; 

— peer-to-peer  or  collaborative  relationships; 

— behavior  (specific  functionality  encapsulated  by  the  component); 

— messages,  that  is,  the  complete  set  of  specific  instructions  necessary  for  invoking  all  of 
the  behaviors  encapsulated  by  the  component; 

— Application  Program  Interface(s)  or  the  interfaces  a component  uses  specifically  to  ac- 
cess services  provided  by  the  SOSAS  notion  of  an  Open  Systems  Environment. 

3.2.13  data  encapsulation:  API  is  a part  of  the  notion  of  data  and  functional  encapsulation 
and  the  concept  of  data  hiding.  Data  encapsulation  refers  to  the  object-oriented  idea  of  grouping 
the  data  and  functions  into  a class  container  (or  black  box.)  Thus,  a queue  class  specification 
offers  the  user  a general  data  representation  (e.g.,  circular  list)  with  a set  of  functions  (create. 
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add,  remove,  delete,  front,  ...)  bundled  under  the  QUEUE  class.  More  interesting  is  the  notion 
of  abstracting  the  queue  elements  (say  a queue  of  integers  vs.  a queue  of  floats)  allowing  a user 
to  specify  the  element  type  since  the  functions  are  identical  (e.g.,  which  could  be  implemented 
with  an  ADA  generic  or  C++  templates.) 

3.2.14  interface:  An  interface  is  a connection  between  modules.  The  interface  is  defined  by 
the  language  the  communicating  modules  use  to  exchange  information.  The  language  is  the 
formal  system  of  signs  and  symbols  and  rules  for  formulation  (syntax)  and  transformation  of 
admissible  expressions.  For  terms  of  this  Working  Draft  Standard  Document,  two  types  of 
interfaces  will  be  discussed,  programmable  interface  and  published  interface.  A programmable 
interface  describes  messages  as  programs  passed  between  modules  that  would  exphcitly  contain 
data  structure  declarations,  data  definition,  program  flow  and  actual  data.  Published  interfaces 
describe  data  size  and  ordering  (or  data  structure)  a priori  as  the  method  to  specify  the  syntax 
of  the  language. 

NOTE  1 - Programmable  interface  languages  contain  special  keywords  or  primitives  to  simplify 
the  process.  For  example,  the  Postscript  U language  contains  special-purpose  keywords  that  denote 
drawing  primitives.  An  appropriate  list  of  primitives  is  critical  to  the  success  of  an  interface.  For  a 
Postscript  interface,  instead  of  sending  a thousand  points  to  define  a shape,  one  invokes  a Postscript 
primitive  shape  function  with  specific  parameters.  In  this  case,  you  send  textual  “programs”  across 
the  interface  (e.g.,  those  written  in  Postscript)  instead  of  raw  data.  Extending  the  language  with 
user-defined  primitives  (e.g.,  subroutines  or  macros)  is  also  available  within  a programmable  inter- 
face. Within  Postscript,  one  can  extend  the  interface  by  defining  user-shape  functions  and  invoking 
them  with  a subroutine  calls  and  a parameter  list. 

The  programmable  interface  is  a powerful,  yet  costly  technique.  It  requires  a high  computational 
overhead  to  interpret  messages.  Time  is  a luxury  that  cannot  be  afforded  in  much  of  the  UTAP 
architecture.  To  achieve  high  performance,  many  interfaces  limit  messages  to  raw  data  consisting  of 
a keyword  and  parameter  list,  formatted  according  to  a published  interface  definition  or  Application 
Programming  Interface  (API).  Such  interfaces  have  a low-overhead  and  are  simple  to  interpret.  The 
published  interface  would  list  acceptable  keyword  and  parameter  syntax  describing  the  module  func- 
tionality and  data  representation  for  an  interface.  Such  interfaces  can  be  as  simple  as  a subroutine 
keyword  and  parameter  list.  Distributed  interfaces  require  an  additional  level  of  packaging  - a sender 
prepares  a message  for  transport  along  a channel  to  the  receiver  module. 

3.2.15  message:  A message  is  an  instance  (or  program)  written  in  the  interface  language.  The 
receiver  interprets  the  message  from  the  sender. 

3.2.16  module:  A module  is  a collection  of  similar  computational  services.  Modules  contain 
software  components  such  as  C++  classes  or  ADA  packages.  A module  consists  of  more  than  a 
box  of  functionality  with  an  explicit  Application  Programming  Interface.  Modules  consist  of: 

— A set  of  functions 

— API’s  for  those  functions 

— A registration  process  that  can  be  invoked  wherein  the  module  registers  with  the  system 

^^Postscript  is  a registered  trademark  of  Adobe  System,  Inc. 
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being  configured  what  its  capabilities  are 

— An  auxiliary  store/database  containing  the  specifications  for  the  current  instantiation 
of  a module. 

3.2.17  open  system:  IEEE  Controls  Magazine  defines  an  open  system  standard  as  “a  specifi- 
cation developed  by  a consensus  process  to  which  any  vendor  can  build  products”.  The  following 
features  are  characteristics  of  “openness”: 

- Products  are  implemented  to  internationally  agreed  standards.  Ideally,  internationally 
agreed  de  jure  standards  are  preferred  to  de  facto  standards,  but  the  latter  are  often  used 
in  practice.  To  be  appropriate,  a de  facto  standard  must  have  a large  base  of  independently 
developed  applications  available,  be  supported  on  a range  of  different  hardware,  can  be 
licensed  for  use  by  anyone,  and  have  international  support. 

— Standards  are  nonexclusive,  nonproprietary,  and  vendor  independent.  A standard  sat- 
isfies this  requirement  if  an  agreed  definition  is  publicly  available,  the  specification  is  not 
owned  or  controlled  by  a company  or  group  of  companies  with  vested  commercial  interests, 
and  no  restrictions  are  imposed  on  its  use. 

- Applications  can  be  moved  as  necessary  between  systems  of  different  makes  and  sizes. 
This  is  more  than  a simple  matter  of  application  portability.  It  is  also  a means  of  ensuring 
that  data  and  user  experience  is  also  portable  between  the  same  application  on  different 
hardware  systems. 

- Usable  information  can  be  exchanged  when  required  between  different  systems.  This  en- 
sures that  data  is  usable  by  different  applications  thereby  ensuring  that  different  applications 
can  work  together.” 

3.2.18  protocol:  The  protocol  describes  the  message  passing  mechanism  and  the  method  in 
which  each  module  acknowledges  receipt  of  a message,  e.g.  ack/nack,  guaranteed  delivery,  in- 
order,  blocking/non-blocking,  time-out,  buffering,  queuing,  persistent,  dynamic.  The  connection 
defines  the  configuration  of  the  interface,  e.g.,  point-to-point,  broadcast,  blackboard. 

3.2.19  telerobotics:  Telerobotics  methods  can  be  separated  into  three  types:  manual  control, 
supervisory  control,  and  fuUy  automatic  control.  The  distinction  between  these  methods  is 
briefly  described  here.  The  term  teleoperation  may  be  used  generically  to  describe  all  telerobotics 
methods  but  is  used  here  in  its  more  common  connotation  of  manual  control.  In  manual  control, 
all  robot  motion  is  specified  by  continuous  input  from  a human,  with  no  additional  motion 
caused  by  a computer.  In  supervisory  control,  robot  motion  may  be  caused  by  either  human 
inputs  or  computer  generated  inputs.  In  fully  automatic  control,  all  robot  motion  is  caused  by 
computer  generated  inputs. 

There  are  two  primary  subsets  of  supervisory  control:  supervised  autonomy  and  shared  control. 
The  distinction  between  them  is  the  nature  of  the  inputs  from  the  operator.  In  shared  control, 
operator  commands  are  sent  during  execution  of  a motion  and  are  merged  with  the  closed  loop 
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motion  generated  automatically.  Therefore,  in  shared  control,  all  inputs  from  the  operator 
are  not  known  a priori  to  execution  of  a motion  since  inputs  during  execution  are  also  used.  In 
supervised  autonomy,  autonomous  commands  are  generated  through  human  interaction,  but  sent 
for  autonomous  execution.  A command  can  be  sent  immediately  or  iteratively  saved,  simulated, 
and  modified  before  sending  it  for  execution  on  the  real  robot.  Also,  individual  commands  can 
be  complete  descriptions  of  the  motion  or  module  commands  specifying  only  modifications  to 
the  control  or  monitoring  of  a specific  module  of  the  remote  system. 


4 Abbreviations 


For  the  purposes  of  this  standard  definition,  the  following  abbreviations  apply. 


ADS 

Analysis  and  Diagnosis  Module 

API 

Application  Programming  Interface 

CORBA 

Common  Object  Request- Broker  Architecture 

COTS 

Commercial  Off  The  Shelf 

DCE 

Distributed  Computing  Environment 

DB 

Data  Base 

DLL 

Dynamically  Linked  Library 

OC 

Object  Calibration 

01 

Operator  Input  Devices 

OM 

Object  Modeling 

OK 

Object  Knowledge 

OSF 

Open  Software  Foundation 

POSIX 

Portable  Operating  System  Interface  for  Computer  Environments 

PTPS 

Parent  Task  Program  Sequencer 

RSC 

Robot/ Axis  Servo  Control 

SC 

Sensor  Control 
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SGD 

Status  Graphics  and  Displays 

SIE 

Standard  Interface  Environment 

SOSAS 

Specification  for  an  Open  System  Architecture  Standard 

ss 

Subsystem  Simulators 

TC 

Tool  Control 

TD 

Trajectory  Description 

TDS 

Task  Description  and  Supervision 

TK 

Task  Knowledge 

TPS 

Task  Program  Sequencer 

TLC 

Subsystem  Task  Level  Control 

TRD 

Trajectory  Description 

VS 

Virtual  Sensor 

XDR 

External  Data  Representation 

5 Conformance  requirements 


5.1  Implementation  Conformance 

A conforming  implementation  shall  meet  aU  of  the  following  criteria; 

a)  The  system  shall  support  all  required  interfaces  defined  within  the  standard.  These 
interfaces  shall  support  the  behavior  described  herein.  The  algorithms  or  other  internal 
mechanisms  used  to  achieve  these  behaviors  is  not  specified  by  the  standard. 

b)  The  system  may  support  additional  features  or  facilities  not  required  by  this  standard. 
Nonstandard  extensions  should  be  identified  as  such  in  the  documentation.  Nonstandard  ex- 
tensions, when  used,  may  improve  the  behavior  of  functions  or  facilities  defined  by  this 
standard,  but  shall  maintain  basic  performance  behavior.  In  the  case  of  nonstandard  ex- 
tensions, the  documentation  shall  define  an  environment  in  which  an  application  can  be 
run  with  the  behavior  specified  by  the  standard.  In  no  case  shall  such  environment  require 
modification  of  a strictly  conforming  application. 
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5.2  Environment  Conformance 

A module  shall  conform  to  the  environment  as  indicated  by  the  configuration  file.  The  envi- 
ronment definition  shall  conform  to  the  profile  specification  as  defined  in  C that  comphes  with 
the  NGC  Open  System  Environment  framework  [SOSAS].  Other  conformance  issues  remain  to 
be  resolved. 


5.3  Documentation  Conformance 

A document  with  the  following  information  shall  be  available  for  an  implementation  claiming 
conformance  to  the  standard. 

This  document  shall  contain  a conformance  statement  that  indicates  the  full  name,  number  and 
date  of  the  standard  that  applies. This  document  shall  contain  a conformance  section  that  hsts 
other  software  standards  used  to  satisfy  the  infrastructure. 

This  document  should  specify  the  behavior  of  the  implementation  of  the  standard  where  imple- 
mentation may  vary. 

This  document  should  specify  the  time-based  performance  of  the  implementation  of  the  standard 
where  implementation  may  vary. 

Modules  complying  with  this  standard  will  supply  a document  that  describes  the  environment 
profile  as  given  the  NGC  Open  System  Environment  framework  [SOSAS]  which  is  defined  in 
Annex  C. 

6 Application  Architecture 


The  UTAP  application  architecture  is  defined  so  as  to  avoid  point  solutions  to  specific  appli- 
cations. Instead,  the  UTAP  architecture  accommodates  different  types  of  robotic  manipulators 
with  different  degrees  of  freedom,  accommodate  different  part  materials  and  part  geometries, 
new  tasks  in  the  workplace,  and  provide  a facility  to  upgrade/change  equipment,  sensors,  and 
feedback  mechanisms  as  technology  advances. 

A reference  model  architecture  is  a guide  as  to  how  to  structure  the  components  in  a system. 
Depending  on  the  application,  a similar,  but  not  necessarily  duplicate  instance  of  the  reference 
architecture  may  be  developed.  The  goal  of  the  reference  model  architecture  is  to  model  the  re- 
lationships among  elemental  components  that  may  exist  in  any  system.  The  goal  of  the  reference 
model  is  to  provide  a framework  as  to  how  to  organize  system  components.  Figure  3 shows  the 
UTAP  application  architecture  in  terms  of  its  elemental  components.  The  architecture  includes 
both  implementation  and  execution  features  although  implementation  and  execution  would  be 
done  at  different  times  by  different  people.  Central  to  the  architecture  is  the  application  pro- 
gram. This  is  the  program  which  is  run  by  the  operator  to  execute  the  telerobotic  task.  The 
application  program  is  separated  into  subsystem  task  programs  and  a parent  task  program.  A 
subsystem  is  characterized  by  having  a separate  task  program.  There  may  be  separate  task 
programs  running  on  separate  controllers  for  different  robots  or  mechanisms,  or  separate  task 
programs  running  on  the  same  controller  hardware.  Coordinated  control  between  separate  task 
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Figure  3 - Telerobot  architecture  for  aircraft  maintenance  and 
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programs  is  achieved  by  direct  communication  between  the  subsystem  task  programs  and/or 
through  communication  with  a parent  task  program  which  communicates  with  the  subsystem 
task  programs  to  coordinate  their  control. 

The  generic  architecture  actually  has  separate  hardware  and  software  architectures  since  for  dif- 
ferent implementations,  software  of  a specific  functionality  may  reside  on  different  computational 
hardware.  For  example,  servo  control  software  could  reside  on  a special  servo  control  board  or 
on  the  same  cpu  board  as  task  level  control.  The  software  module  has  a clear  functionality,  but 
where  it  is  located  is  application  dependent. 

The  NGC  terminology  for  components  is  expanded  here  to  separate  components  into  three  types 
of  components:  architecture  components  (AC),  hardware  components  (HC),  and  software 
components  (SC).  Architecture  components  are  the  components  consistent  with  NGC  which  are 
not  hardware  or  software  specific,  but  are  functionality  specific,  and  describe  the  application 
architecture.  Hardware  and  software  components  are  used  in  this  report  to  specify  the  unique 
hardware  and  software  modules  of  the  system.  This  distinction  is  made  because  it  is  desired 
that’  the  components  be  replaceable  and  software  can  be  replaced  independently  of  hardware 
and  vice-versa.  The  architecture  components  are  described  in  Annex  A. 


6.1  Hardware  Architecture 


The  hardware  architecture  is  shown  in  figure  4.  The  hardware  components  are  separated 


Figure  4 - Hardware  Architecture 

into  physical  hardware  items  that  might  be  purchased.  Hardware  compatibility  is  a critical 
feature  of  an  open  architecture  controller.  Hardware  compatibility  implies  physical  connection 
between  pieces  of  hardware.  The  connection  can  be  communication  lines  such  as  serial,  parallel, 
and  ethernet  cables,  and  the  backplane  which  cards  can  plug  into.  These  connection  standards 
are  not  separate  components,  but  are  features  between  hardware  components  to  make  them 
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compatible  in  an  open  system. 

A common  backplane  for  computer  cards  to  plug  into  is  a critical  feature  for  hardware  com- 
patibility. Candidate  backplanes  for  standardization  include  VME,  ISA,  EISA,  and  VISA.  The 
backplane  must  support  multiple  processors  and  have  sufficient  throughput.  It  is  important  that 
the  backplane  specification  is  rigorous,  complete,  and  unambiguous.  A weU  specified  backplane 
allows  suppliers  to  develop  boards  for  the  backplane  knowing  the  constraints  for  a board  and 
for  each  pin,  thereby  ensuring  safety  for  the  hardware.  The  allowable  power  per  board  needs  to 
be  specified.  Each  pin  that  might  be  used  by  multiple  boards  needs  to  be  well  specified.  If  a 
pin  is  not  well  specified,  then  a supplier  may  not  know  how  another  board  in  a system  might 
use  the  pin  and  therefore  not  be  able  to  guarantee  safety  if  the  pin  is  used. 

To  allow  a spectrum  of  common  architecture  controllers,  multiple  backplane  options  should 
be  allowed,  corresponding  to  lesser  capability  inexpensive  systems  and  greater  capability  more 
expensive  systems.  Perhaps  one  low  end  backplane  and  one  high  end  backplane  should  be 
selected.  As  with  the  NGC  concept,  the  backplane  is  not  specified  here.  The  controller  developer 
selects  the  backplane  from  a standard  list  for  their  specific  profile.  It  is  felt  that  a small  number’ 
of  backplanes  will  emerge.  It  is  felt  that  presently  the  VME  backplane  is  the  desired  backplane 
for  high  end,  more  expensive,  systems  and  ISA  and  EISA  for  lower  end,  less  expensive,  systems. 

The  VME  bus  meets  the  backplane  criterion  the  best  of  the  backplanes  considered.  It  specifies 
the  allowable  power  draw  per  board.  It’s  Pi  bus  is  completely  defined.  The  P2  bus  has  some 
defined  lines  and  some  lines  left  open  to  the  user.  The  lines  left  open  to  the  user  must  be  further 
specified  for  use  in  an  open  architecture  system.  The  other  backplanes  are  less  expensive  and 
could  be  used  in  less  demanding,  or  diverse,  applications  than  the  VME  bus. 

The  hardware  components  are  separated  into  types  of  hardware  components  as  described  in 
Annex  A.  There  may  be  one  (e.g.,  interface  controller)  or  more  (e.g.,  device  controller)  hardware 
components  in  the  system  for  each  type  of  hardware  component.  Also,  the  hardware  component 
types  apply  for  various  device  types  including  tools,  sensors  and  manipulators. 


6.2  Software  Architecture 

The  software  architecture  is  separated  into  functional  types  of  software  modules,  the  software 
modules  themselves,  and  the  application  programs.  Software  modules  are  described  in  this  report 
as  modules,  components  and  agents.  The  software  modules,  or  components,  can  actually  be 
aggregates  of  multiple  software  modules  which  collectively  have  specified  responsibility,  input  and 
output.  Modules  and  components  both  imply  a software  entity  with  a specific  responsibility  and 
inputs  and  outputs.  The  term  agent  also  implies  a software  entity  with  a specific  responsibility 
and  inputs  and  outputs,  but  it  also  implies  that  this  software  entity  runs  as  a separate  thread 
of  execution.  An  agent  is  likely  to  be  an  aggregation  of  software  modules  running  as  a separate 
thread  of  execution  with  a specified  interface.  Agent  based  systems  have  the  benefit  of  being 
highly  modular  and  reconfigurable  with  easily  replaceable  individual  agents.  Consistent  with  an 
NGC  architecture,  the  software  modules  can  be  implemented  as  agents,  i.e.,  as  separate  threads 
of  execution.  But,  agent  based  systems  have  not  been  demonstrated  sufficiently  in  real-time 
applications  to  justify  a requirement  for  the  use  of  agents.  Therefore,  the  software  modules  of 
the  system  will  be  described  as  components  with  well  defined  responsibilities,  inputs  and  outputs, 
but  with  the  implementation  details,  e.g.,  the  use  of  agents  or  not,  left  to  the  application  system 
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implementation . 

The  software  module  types  and  organization  are  first  described  followed  by  their  interaction  for 
supervisory  and  shared  control  and  then  by  descriptions  of  the  software  modules  as  components. 


6.2.1  Software  Module  Functional  Types 


The  software  architecture  is  shown  in  figure  5.  Figure  5 distinguishes  the  types  of  software 


Figure  5 — Software  Architecture 


modules,  or  equivalently,  components,  for  execution  of  an  application  program.  A second  fig- 
ure, 6,  shows  how  software  modules  are  grouped  and  communication  is  constrained.  The 
ovals  indicate  which  components  can  communicate  directly  with  each  other;  modules  within  the 
same  oval  can  communicate  directly.  It  is  a goal  to  separate  the  different  types  of  software  com- 
ponents and  specify  their  interfaces  so  that  these  can  be  developed  independently.  Libraries  of 
application  programs,  macro  commands,  or  task  control  modules  could  then  be  selected,  perhaps 
purchased,  as  needed  for  a specific  application. 

The  components  of  the  architecture  correspond  to  the  components  shown  in  figure  1,  but  the 
modules  of  figure  5 indicate  the  modules  for  task  execution  whereas  the  modules  of  figure  1 show 
components  for  both  development  and  execution.  The  operator  interface  together  with  the  ap- 
plication program  represent  the  Application  module  of  figure  1.  The  task  control  represents  the 
Interpreter,  Trajectory  Planner  and  Controller  and  the  task-device  map  represents  the  Inverse 
Kinematics  of  figure  1.  The  device  control  together  with  the  device  driver  represents  the  Servo 
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Control  of  figure  1.  The  language  is  an  integral  part  of  the  architecture  but  is  not  a component 
since  it  does  not  process  information.  The  architecture  does  not  specify  a translator  module 
although  one  would  be  needed  if  the  language  for  task  description  is  different  from  the  language 
of  the  commands  sequenced  in  task  execution.  The  macro  commands  and  task  program  editor 
of  the  architecture  represent  the  Tools  component  of  figure  1. 

The  groupings  of  software  modules  given  in  figure  6 are  functional.  Where  the  specific  software 
modules  reside  will  depend  on  the  profile  of  the  system  selected.  The  options  for  mapping 
software  module  types  onto  the  hardware  is  given  in  figure  7. 

The  types  of  software  modules  that  will  be  in  a controller  are  described  below,  followed  by 
descriptions  of  the  actual  software  modules. 


6. 2. 1.1  Operating  System 

The  operating  system  is  not  one  of  the  modules  of  the  architecture.  Rather  it  is  a common  service 
to  the  modules.  There  is  likely  to  be  separate  operating  systems  for  the  planning  and  real-time 
control  parts  of  the  system  - running  on  the  interface  controller  versus  running  on  the  task 
controller  computers.  Standard  operating  systems  would  be  very  useful  for  development  of  an 
open  architecture  controller.  Then  all  software  modules  could  be  developed  and  independently 
tested  against  given  versions  of  an  operating  system.  This  would  simplify  software  integration. 
If  specific  operating  systems  are  not  specified,  then  the  constraints  on  the  allowable  operating 
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Hardware 


Software 


Figure  7 — Software  to  Hardware  Map  Options 


system  options  should  be  specified,  e.g.,  POSIX  compatibility.  The  selected  operating  systems 
will  be  part  of  the  architecture  profile. 

6. 2. 1.2  Operator  Interface 

The  operator  interface  is  the  group  of  software  which  controls  the  inputs  and  outputs  to  the 
operator.  This  includes  interaction  with  the  application  developer  and  the  operator.  The  oper- 
ator interface  may  be  implemented  in  various  forms,  but  a goal  is  to  have  a common  method 
of  interacting  with  systems  across  multiple  applications.  There  will  likely  be  multiple  common 
interface  methods,  e.g.,  iconic  systems  with  graphics  simulation,  or  simpler  (and  less  expensive) 
ASCII  based  inputs. 

The  operator  interface  software  wiU  run  on  the  operator  interface  computer  hardware.  In  some 
cases  the  operator  interface  computer  wiU  be  the  same  system  as  the  task  controUer  hardware. 
This  computer  would  then  have  to  support  the  operator  interface  and  task  control  software 
systems. 

6.2.2  Application  Program 

An  appUcation  program  is  the  stored  program  which,  when  executed,  wiU  perform  a task.  An 
appUcation  program  may  consist  of  subsystem  task  programs  and  a parent  task  program.  A 
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subsystem  task  program  can  have  multiple  threads  of  execution,  e.g.,  one  for  task  control  and 
another  for  status  update  to  the  operator  interface.  Application  programs  consist  of  sequences 
of  macro  commands  and  a limited  set  of  conditionals  and  math  operations. 

6. 2. 2.1  Macro  Commands 

Macro  commands  encapsulate  an  algorithm  which  provides  a type  of  capability,  e.g.,  free  motion 
command  or  grinding  command.  Macro  commands  wiU  have  a given  set  of  parameters,  but  may 
have  various  internal  implementations.  Macro  commands  are  automatically  decomposed  and 
translated  into  commands  to  control  the  task  level  control. 


6. 2. 2. 2  Task  Control 

Task  control  occurs  when  the  task  programs  are  executed.  The  task  programs  make  calls  to 
the  task  control  modules.  There  will  be  many  task  control  modules  including  force  control, 
trajectory  generator,  visual  servoing,  monitoring,  and  motion  command  modules.  By  specifying 
the  interfaces  of  the  modules,  modules  can  be  acquired  from  different  sources.  The  various 
sources  of  motion  wiU  generate  motion  commands  which  the  motion  fusion  module  will  merge 
into  a command  to  the  device  to  be  controlled. 


6. 2. 2. 3 Task-Device  Map 

The  task  level  command  is  transformed  into  the  actuator  coordinates,  e.g.,  joint  angles,  velocities 
or  torques,  with  a task-device  map  module.  A separate  module  is  used  to  transform  measured 
data  from  the  device  coordinates  to  the  task  space  coordinates.  This  module  is  mechanism 
dependent.  Sensor  commands  also  go  through  a task-device  functional  module  to  transform  the 
command  to  the  coordinates  of  the  sensor,  and  when  read,  from  the  sensor  frame  to  the  task 
control  frame. 

6. 2. 2. 4 Device  Control 

The  device  control  software  modules  provide  the  control  of  the  axes  of  the  mechanism  or  interface 
to  sensors.  It  also  provides  the  interpolation  of  setpoints  for  the  device  servo  control  since  this  is 
likely  running  faster  than  the  task  level  control  and  thus  has  multiple  cycles  between  commands 
from  the  task  level  control.  Servo  control  of  joints  would  be  done  by  device  control  software 
modules.  The  device  control  software  modules  might  reside  on  the  task  controller  or  device 
controller  hardware.  For  example,  a controller  may  allow  joint  servo  control  software  to  reside 
on  the  task  controller  board  with  the  task  control  software.  The  device  controller  hardware 
might  then  just  be  a D/A  card.  Alternatively,  a servo  control  card  could  be  used  for  the  device 
controller  hardware  which  would  have  the  servo  control  device  control  software  on  it.  The  device 
control  module  communicates  with  the  power  interface  to  the  device,  e.g.,  PWM  commands  to 
PWM  drives,  analog  commands  to  analog  drives,  signal  interfaces  to  sensors. 
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6. 2. 2. 5 Device  Driver 

The  device  driver  software  is  hardware  dependent,  residing  on  the  device  controller  hardware. 
This  component  sends  commands  and  receives  status  from  the  device  amplifier  hardware,  e.g., 
voltage  or  PWM  signals. 

6. 2. 2. 6 SW  Architecture  for  Supervisory  and  Shared  Control 

A unified  supervisory  and  shared  control  telerobotic  system  has  the  same  architecture  for  all 
modes  of  control:  teleoperation,  shared  control  and  supervised  autonomy.  The  fundamental 
system  provides  task  description  and  task  program  sequencing.  The  commands  in  a sequence 
can  imply  autonomous  execution  or  a mix  of  autonomy  and  teleoperation  inputs.  There  are 
two  basic  paths  for  operator  inputs.  The  inputs  can  be  incorporated  into  parameters  in  the 
command  path  from  the  operator  interface  to  the  task  execution  system,  or  hand  controller 
inputs  from  the  operator  can  be  treated  as  sensory  input  to  the  real-time  task  level  control. 
In  both  cases  they  have  similar  form  as  other  types  of  information.  The  system  is  therefore 
essentially  an  autonomous  control  system  which  allows  operator  inputs  during  execution. 

Different  components  of  the  system  might  run  synchronously,  asynchronously  or  upon  request. 
For  example,  in  the  real  time  control,  the  closed  loop  control  components  might  run  asyn- 
chronously at  different  rates,  reading  available  data,  and  producing  data  to  be  read.  Slowly 
changing  information  can  be  computed  at  a slower  rate  than  it  is  used.  Alternatively,  these 
components  could  be  synchronized  and  called  in  a given  order.  The  task  planning  components 
will  not  be  called  at  the  high  rates  that  the  task  control  components  are  run.  Therefore,  they 
could  more  readily  be  implemented  as  agents,  responding  only  when  their  services  are  needed. 

There  may  be  multiple  sources  for  motion  of  the  tool,  and  therefore  the  manipulator,  including 
hand  controller,  trajectory  generator,  and  closed  loop  sensor  based  control  such  as  force  control 
and  proximity  control.  Motion  commands  from  each  of  these  sources  can  be  generated  by  specific 
software  components  associated  with  the  motion  source.  These  motion  commands  then  have  to 
be  merged.  This  merging  is  done  by  the  motion  fusion  component.  There  are  many  ways  that 
motion  can  be  merged,  or  fused,  with  motion  commands  of  various  types,  e.g.,  disturbance  forces, 
incremental  motion,  velocities  and  absolute  positions.  The  motion  source  components  therefore 
have  to  generate  motion  commands  which  are  consistent  with  the  motion  fusion  component 
input  types. 


7 Interface  Environment 


The  UTAP  architecture  is  a modularized  arrangement  of  control  services.  As  a result,  a mod- 
ularized system  reduces  complexity  and  makes  it  easier  to  understand,  design,  and  implement 
the  system.  The  complementary  result  of  the  modularization  of  a system  into  components  are 
interfaces.  An  interface  provides  access  to  a module’s  services  where  each  interface  is  defined 
by  a language  that  specifies  the  tokens  (or  keywords),  syntax  (or  format),  and  semantics  (or 
legitimate  values  and  interpretation)  that  are  acceptable  to  a module.  Indeed,  one  could  have 
several  interface  languages  to  the  same  module  of  computational  services.  The  goal  of  a generic 
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interface  is  to  unify  similar  computational  services  under  one,  general-purpose,  access  mechanism 
supporting  a wide  range  of  uses. 

The  major  observation  within  the  UTAP  Interface  Environment  is  that  an  interface  is  composed 
of  two  elements,  a language  and  a protocol.  This  observation  can  be  represented  by  the  following 
equation; 

Interface  = Language  -}-  Protocol  (1) 

Which  is  equivalent  to  saying  that  an  interface  is  defined  as  “What-to-pass”  plus  “How-to-Pass.” 

In  order  to  realize  the  hard  real-time  processing  demands  of  motion  control,  one  requires  that 
UTAP  interface  languages  must  be  efficient  and  allow  timely  transmission  and  interpretation 
of  data.  A modeling  schism  develops  attempting  to  meet  the  desire  for  generality  and  the 
requirement  for  performance.  A more  expressive  language  is  desirable  but  suffers  the  penalty 
of  an  increased  performance  requirement.  The  UTAP  Interface  Environment  is  framed  by  the 
assumptions  made  in  order  to  resolve  conflicting  notions  of  interface  definition.  (See  Annex  G 
for  further  discussion  of  these  issues.) 

NOTE  1 - Ultimately,  the  following  assumptions  were  made  for  this  Working  Draft  Standard  Doc- 
ument. The  first  assumption  was  to  focus  on  what-to-pass,  not  how-to-pass.  The  second  assumption 
was  to  minimize  complexity  and  adopt  a simple  definition  style.  A simple  language  strategy  would 
appeal  to  a greater  audience.  Initial  attempts  at  an  elegant  software  solution  were  confusing  and 
drew  attention  away  from  the  focus  of  the  problem  - defining  the  language  primitives.  The  third  as- 
sumption was  that  a “published”  interface  would  be  necessary.  A published  interface  would  require 
minimal  interpretation  and  allow  shared  memory  schemes.  The  fourth  assumption  was  to  allow 
both  measurement  units  and  computer  representation  to  be  adjustable.  The  environment  would 
explicitly  define  message  primitives  for  different  units  and  representation.  The  fifth  assumption  was 
to  provide  for  symbolic  manipulation  of  data,  in  that,  although  the  message  definitions  were  in  a 
raw  format,  textual  information  would  be  required  also. 

The  definition  of  interfaces  consists  of  two  elements:  Configuration  and  Language  Framework. 

Configuration  deals  with  naming,  system  identification,  narrowing  the  scope  of  the  problem 
through  labelling,  and  system  scaling.  Naming  includes  acronyms,  message  naming  conventions 
and  communication  channel  naming  conventions.  Configuration  includes  classification,  resolving 
duplicate  module  types,  dynamic  configuration  and  attachment  of  a protocol  to  channel.  A 
service  directory  is  associated  with  each  module  that  describes  the  permissible  set  of  messages 
into/outof  the  module.  This  capability  allows  scaling  of  the  system. 

The  Language  Framework  covers  Information  Models  and  the  Interface  Language. 

Information  Models  define  the  data  representation  within  the  messages.  A substantive  infor- 
mation model  is  required  for  interoperability.  One  could  define  everything  as  tokens,  but  this 
offers  little  in  helping  with  the  standardization  process.  The  Information  Model  includes  1) 
domain-independent  items  or  generic  data  definitions;  2)  feature-based  definitions  such  a ge- 
ometry, topology,  shape,  and  patterns;  and  3)  object  knowledge.  Object  knowledge  covers  the 
devices,  parts,  modules,  and  general  system  state  information.  Object  knowledge  is  defined  with 
attributes,  and  access  to  information  is  through  query/response  connection. 

The  UTAP  Interface  Language  was  defined  as  a set  of  messages.  The  C/C-1-+  language  was  used 
to  define  messages.  There  is  a trade-off  between  interface  language  complexity  and  performance. 
The  distributed  and  real-time  nature  of  the  UTAP  predicated  an  explicit,  simple  approach  to 
defining  messages.  The  UTAP  message  defining  style  uses  #defines  to  enumerate  message  name 
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and  id,  plus  gives  data  structures  to  each  message  id.  The  information  models  (data  declarations) 
and  messages  were  defined  within  C/C++  header  files.  The  information  models  and  messages 
are  compilable.  A more  abstract  Application  Programming  Interface  is  defined  and  was  derived 
by  running  a filter  on  the  message  definitions. 

Generic  messages  were  defined  that  are  applicable  to  aU  modules  in  the  UTAP  architecture. 
Mode  and  state  change  commands  are  covered  by  the  generic  messages.  Such  state  change 
commands  include:  start,  halt,  hold,  resume,  suspend,  etc.  Extensibility  and  customization  are 
provided  with  the  MACRO,  and  PLAN  set  of  messages.  Synchronization  of  messages  is  provided 
with  the  BLOCK  and  EVENT  set  of  messages. 

The  UTAP  framework  provides  for  these  major  styles  of  messages  - sensor/effector  control 
and  query /response.  The  UTAP  sensor /effector  (S/E)  control  interfaces  apply  programming 
concepts  from  servo  control,  programmable  input /output  and  the  programming  format  RS274 
[EIA274].  The  S/E  control  interfaces  divide  communication  into  1)  mode  and  2)  action  messages. 
The  mode  messages  provide  for  event  sequencing  (e.g.,  start,  halt,  abort,  etc.),  set-up,  algorithm 
selection  (e.g.  PID,  FEEDFORWARD,  etc.)  and  provide  for  loading  control  parameters.  The 
action  messages  either  write  a command  or  initiate  a sensor  reading.  Action  messages  treat 
communication  as  clocked  data  flow.  Query /Response  (Q/R)  interfaces  adopt  a similar  strategy 
but  one  generally  assumes  one  cycle  per  clocked  data  flow.  The  Q/R  data  can  be  of  the  form  of 
a query  message  from  the  superior  to  the  subordinate,  or  as  a reading  from  the  subordinate  to 
the  superior  and/or  Object  Knowledge  module. 

7.1  Viewpoints 

Some  interfaces  do  not  need  to  have  an  innate  understanding  of  the  control  domain  and  wiU  be 
merely  performing  symbolic  manipulation  of  the  interface  data.  For  example,  an  Object  Knowl- 
edge Base  or  Operator  GUI  do  not  need  to  understand  the  application  in  order  to  store/retrieve 
or  display  the  information.  Instead,  these  modules  must  have  a systematic  (and  symbolic)  means 
of  receiving  system  information  and  capabilities,  and  then  organizing  this  information  for  either 
the  user  or  other  modules  in  the  system.  For  example,  I as  a user  may  wish  to  override  the  feed 
rate  for  a particular  task  if  I observe  chatter.  The  GUI  cannot  understand  why  Pm  changing 
the  feed  rate.  Instead,  the  GUI  may  have  limits  on  the  acceptable  range  of  numeric  values,  and 
pass  the  new  value  to  the  control  system  which  makes  the  determination  for  the  validity  of  the 
new  data  value. 

Likewise,  when  one  module  requests  the  value  of  the  feed  rate  from  the  Object  Knowledge 
Module,  the  data  manager  doesn’t  need  to  know  the  purpose  of  the  feed  rate,  but  rather,  it 
needs  to  know  its  computer  representation  (double),  its  range  of  legal  values,  and  possibly  all 
the  users  of  this  information  throughout  the  system. 

The  UTAP  interfaces  will  provide  a capability,  tasking,  and  data  framework  for  the  modules 
that  may  only  require  symbolic  manipulation  of  data.  The  capability  framework  specifies  what 
resources  are  in  the  system,  e.g.,  robots,  tools  and  sensors.  The  tasking  framework  will  provide 
the  necessary  knowledge  about  how  the  capabilities  can  be  used.  The  data  framework  provides 
an  all-encompassing  description  of  the  potential  data  that  the  system  has  at  its  disposal.  It  is 
foolish  for  the  system  to  pass  every  conceivable  variable  to  the  Object  Knowledge  Base.  Instead, 
we  win  assume  that  configuration  of  data  posting,  data  viewing  and  data  modifying  is  possible. 
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For  instance,  various  configurations  could  define  what  values  are  periodically  posted  to  the  object 
knowledge  base,  what  values  are  visually  presented  to  the  user,  what  presentation  style  the  user 
prefers  to  view  data,  etc. 


8 UTAP  Information  Models 


The  UTAP  applications  operate  on  such  parts  as  wings,  fuselages,  and  other  plane  related  parts. 
These  parts  can  be  described  as  a combination  of  geometry,  topology  and  shape  to  derive  UTAP 
features.  These  features  are  used  to  identify  the  focus  of  attention  for  the  tooling  operation. 
For  the  initial  phase  of  the  UTAP,  features  will  be  described  as  simple  shapes  that  are  filled  by 
motion  patterns. 

The  UTAP  framework  will  use  information  models  to  describe  part  features  and  system  at- 
tributes. Currently,  the  information  models  include  generic  types,  part  information  models, 
and  system  data  definitions.  Generic  information  models  cover  domain-independent  types.  The 
generics  include  basic  data  types  including:  mode  directive,  generic-directives,  user  type,  mode 
states,  results,  and  a state-type.  The  part  information  models  define  measurement  units,  repre- 
sentation units,  features  and  object  attributes  required  of  the  system.  System  data  definitions 
are  intended  to  cover  sensing  and  control  attributes. 

The  sum  of  these  information  models  describe  the  Object  Knowledge  and  are  preliminary.  The 
files  generic-defs.h,  utapinfo-model.h  and  utap-data-defs.h  in  Annex  H.3  present  the  current 
state  of  these  definitions.  Presently,  the  feature-based  information  model  is  relatively  modest. 
We  have  provided  for  an  evolutionary  path  to  allow  for  growth  of  potential  part  shape  geometries. 
The  ISO  STEP  Part  for  Geometrical  Shape  and  Material  Information  Models  [STEP42]  covers 
a more  complete  range  of  data  modelling. 

NOTE  1 - A translation  from  EXPRESS  Part  Model  into  a C-f-f  language  information  model  can 
be  done,  and  was  done  to  derive  the  current  set  of  data  definitions.  To  provide  for  a broader  set  of 
part  description,  the  STEP  Part  42  geometrical  models  could  be  substituted  for  the  current  data 
definitions  - but  is  beyond  the  scope  of  the  current  level  of  effort. 


8.1  Shape  Geometries 

For  the  sake  of  clarity  only  the  range  of  part  shapes  that  are  foreseen  within  the  scenarios  will 
be  addressed.  These  parts  are  of  course  a small  subset  of  the  realm  of  potential  parts  shapes. 
The  major  assumption  to  the  current  definition  of  the  UTAP  part  geometry  is  that  the  operator 
will  define  or  choose  the  workpart  geometry  from  a set  of  prescribed  shape  models. 

The  UTAP  interfaces  have  a preliminary  geometric  shape  model  that  describes  the  shapes  re- 
quired within  the  application  scenarios.  Such  shapes  can  be  one,  two  or  three  dimensional.  The 
shape  dimensionality  specifies  the  geometric  form  of  a topological  or  geometric  entity.  Edges 
(curves).  Faces  (surfaces)  and  shells(volumes)  have  dimensionality  of  1,  2,  and  3 respectively. 
By  convention  a Vertex  (point)  has  dimensionality  of  0.  These  geometric  shapes  required  of  the 
UTAP  interfaces  include: 

— ID  - surface,  planar  or  curvilinear  edge 
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— 2D  - rectangle,  circle,  polygon  or  connected  edge  list 

- 3D  - box,  cylinder. 

The  features  can  be  embedded  within  each  other.  This  capability  allows  us  to  define  circu- 
lar/rectangular obstacles  within  our  workarea  feature. 


8.2  Patterns 

A type  of  motion  within  the  work  volume  wiU  be  termed  the  motion  pattern.  Some  patterns  are 
merely  shorthand  notation  for  a larger  set  of  motions.  For  example,  a raster  motion  sweep  can  be 
composed  of  a set  of  linear  motions.  But,  it  is  more  intuitive  to  the  operator  (and  programmer) 
to  define  a raster  pattern  within  a rectangle  workarea.  Patterns  can  be  shape  fill  patterns  or 
edge  patterns.  One  is  either  applying  a motion  pattern  to  the  face  of  a part  or  to  the  edge  of  a 
part. 

The  edge  patterns  are: 

— exact  or  within  some  tolerance  along  edge 

— sine  or  square- wave  weave  (e.g.,  for  arc- welding)  The  fill  patterns  are: 

— horizontal  and  vertical  raster 

— orbital  type  motion 

— dithered  or  chaotic  motion 

— concentric  circle  fiU. 

Of  course,  these  definitions  are  not  complete  but  appear  to  handle  the  task  scenarios.  New 
pattern  definitions  can  easily  be  added  by  a systems  programmer  as  the  need  arises. 


8.3  Features 

A UTAP  feature  is  a combination  of  a geometrical  shape  and  pattern  to  describe  the  motion 
applied  to  that  shape.  For  the  UTAP  application  domain,  the  primary  features  will  be  pattern 
motions  within  faces  of  different  geometrical  shape  - e.g.,  flat  surfaces  with  rectangular  and 
circular  features  or,  curved  surfaces  with  conic  features.  In  this  case  the  faces  (and  their  con- 
stituent edges,  vertices,  surfaces,  etc.)  are  the  primitives  that  can  also  be  operated  on.  Given 
the  shape  we  must  then  describe  the  motion  pattern  that  will  be  applied  to  the  feature.  Thus, 
we  define  a feature  with  the  following  equation: 

FEATU RE  = shape  -|-  pattern  (2) 


Features  are  constructed  using  the  following  base  definitions: 
- GEOMETRY:  gpoint,  vector,  pose,  transform,  arc 
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- TOPOLOGY:  tpoint,  vertex,  edge,  edgeJist,  loop,  face 

- SHAPE:  box,  rectangle,  helix 

- PATTERN:  edge.pattern,  blend-pattern,  face-pattern,  sheU-pattern. 

The  part  shape  geometry  determines  the  work  volume.  The  topology  is  used  to  define  bound- 
aries. Shape  is  derived  from  geometry  and/or  topology.  Most  of  the  application  scenarios  involve 
tooling  the  surface  area  or  face  of  a part.  To  cover  the  surface  a series  of  motion  patterns  will 
be  required. 


9 Integration  and  Configuration  Management 


The  UTAP  architecture  emphasizes  telerobotic  control.  Because  of  this,  the  UTAP  architecture 
is  divided  into  a REMOTE  teleoperated  partition  and  a LOCAL  motion  and  tooling  control  par- 
tition. Although  the  REMOTE  topology  of  the  UTAP  architecture  is  a static  arrangement  (i.e., 
they  is  only  one  instance  of  many  of  the  modules),  the  LOCAL  topology  will  vary  between  ac- 
tual systems.  For  the  LOCAL  partition,  the  UTAP  architecture  describes  a topology  framework 
for  composing  modules.  Identical  modules  can  exist  as  subordinates  to  the  same  superior.  For 
these  modules  to  be  configured  in  a complete  topology,  an  identification  or  naming  convention 
is  required.  With  a naming  convention,  a directive  will  be  sent  to  the  proper  subordinate. 

A classification  framework  helps  bound  the  range  of  module  capabilities  and  to  provide  for  a 
smooth  evolutionary  path.  For  comparison,  the  term  “printer”  - although  descriptive  - can 
be  vague.  One  can  have  a color  printer,  a dot  matrix  printer,  a laser  printer,  ad  infinitum. 
Without  a classification  framework,  one  cannot  accurately  determine  the  expected  capabilities 
of  the  modules.  Before  one  can  define  interfaces  one  must  categorize  the  range  of  modules  in  a 
UTAP  system.  In  turn,  proper  categorization  of  UTAP  systems  wiU  provide  a more  coherent 
framework  for  defining  the  interfaces. 

9.1  Identification 

The  UTAP  describes  an  architecture  that  can  vary  in  size  and  complexity.  For  some  of  these 
modules,  only  a single-instance  of  the  module  exists  in  a system.  These  modules  include  01, 
OM,  OC,  TD,  TDS,  TK,  FTPS,  SGD,  AD,  and  SS.  For  the  remaining  modules  (i.e.,  TPS, 
TLC,  SC,  RSC,  TC,  and  VS),  multiple-instances  can  exist  in  the  system  simultaneously.  The 
variability  of  the  number  and  scope  of  the  module  members  means  the  system  architecture  can 
vary.  To  quantify  the  size  and  scope  of  the  architecture,  one  is  required  to  1)  enumerate  the 
active  single-instance  modules  in  the  system  and  2)  identify  and  categorize  the  multi-instance 
modules. 

To  define  the  multi-instance  modules,  the  identity,  the  grouping,  and  the  relationship  of  modules 
must  be  defined.  The  multi-instance  modules  must  be  declared  and  linked  to  the  relevant  supe- 
rior/owner /parent.  Multi-instance  modules  require  a unique  naming  convention.  The  proposed 
syntax  for  module  naming  is  the  following: 

module-list ;=  module  { module-list  } 
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module module.name : identifier 

This  syntax  enables  a system  to  be  described  as  a tree.  Some  modules  are  capable  of  controlling 
multiple  subordinates  of  the  same  module  type.  Each  subordinate  of  identical  module  type  must 
have  an  instance  identifier.  For  example,  there  can  be  multiple  Task  Level  Control  modules  i.e, 
TLC:A,  TLC:B.  In  turn,  each  of  these  modules  is  capable  of  controlling  a subsystem,  e.g., 
TLC:A:TOOL:A,  TLC:A:TOOL:B. 

9.2  Classification 

The  UTAP  architecture  contains  a list  of  20  modules.  This  architecture  has  the  potential  to 
describe  a broad  range  of  systems.  The  realm  of  possibilities  should  be  narrowed  to  allow 
ranges  of  compatibility.  To  achieve  compatibility,  one  needs  to  attach  labels  to  identify  the 
types  of  modules.  Table  1 describes  a naming  scheme  that  classifies  modules  with  type  labels 
and  illustrates  the  operational  relationship  among  modules.  Those  types  that  have  a preceding 
asterisk  will  not  be  considered  in  the  UTAP  at  this  time. 

9.3  Configuration  File  Format 

The  System  Configuration  Files  will  be  responsible  for  defining  the  architectural  tree.  The 
System  Configuration  Files  are  a combination  of  1)  the  multiplicity  of  modules,  and  2)  the 
classification  labeling  scheme.  Examples  are  given  in  Annex  annexrexample.  The  purpose  of  the 
tables  is  to  assist  in  determining  module  interconnections  and  interface  naming  convention.  The 
exact  format  of  these  file  is  not  currently  defined.  There  is  great  potential  for  the  configuration 
file  that  will  not  be  addressed  here. 


9.4  Module  Specification 

The  conceptual  model  forms  a framework  for  the  required  functionality  required  of  a UTAP 
module  interfaces.  The  UTAP  conceptual  interface  framework  will  be  described  as  with  a set  of 
component  units.  Figure  8 illustrates  a conceptual  model  of  the  UTAP  module  and  the  com- 
ponent units.  In  this  conceptual  model,  the  UTAP  will  adopt  the  strategy  that  a module  must 
publish  a SERVICE  PROFILE  of  accepted  messages  and  postable  data.  The  SERVICE  PRO- 
FILE is  the  umbrella  under  which  a module  declares  its  capabilities.  The  SERVICE  PROFILE 
unit  contains  a slot  for  defining  the  timing  of  the  module.  A conceptual  module  contains  a CLI 
or  command  line  interface  unit  that  receives  either  transmitted  command  messages  or  has  the 
ability  to  read  programs  or  commands  from  disk.  The  CLI  is  responsible  overseeing  the  set  up  of 
modes  and  PARAMETERS  for  a given  module.  The  POST  unit  within  the  conceptual  model  is 
responsible  for  maintaining  the  module  output  updates.  These  output  updates  are  periodically 
sent  to  either  the  Object  Knowledge  module  or  the  SUPERIOR  module.  The  PROG  MACROS 
unit  allows  aggregating  and  naming  of  parameter  or  command  sets. 

Annex  C contains  boilerplate  Service  Profile  checklists  for  the  remote  modules. 
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QFMP me  omumwc* 

BEGIN  BLOCK,  END  BLOCK 
BEOW.HACftO.  END  UACNO,  USE.UACRO 
BEGIN  PLAN.  END  PLAN,  USE  PLAN 
BEGB4_EVENT,  END  EVENT 
USE  SELECTION  ID.  USEJUOS.UASK 


STARTUP  BHUTDOWN.ftESET  ^ULT 
B4ABL£(W).  DISABLE(1tf>.  ESTOP 
BIIT.81ART.8T0PAB0RT 
SUSPEND, RESUNE, 
(BEG1N.NEXT.CLEAR)  BMGLE  STEP, 


Figure  8 - Module  Specification  Model 


9.4.1  Scaling 

The  system  should  allow  scaling.  The  set  of  UTAP  messages  is  quite  extensive.  It  is  not 
expected  that  all  modules  should  accommodate  every  interface  message.  Further,  some  systems 
will  specialize  in  certain  aspects  of  control  or  sensing,  and  completely  ignore  some  aspects  of  a 
UTAP  module  interface.  The  goal  of  the  UTAP  was  to  scale  options  through  the  message  list. 
Many  of  the  messages  could  be  combined  under  a broader  message  category  but  this  creates  a 
problem.  How  do  you  say  that  I accept  this  message  but  not  a certain  part  of  the  message? 
It  was  felt  that  scaling  would  be  best  accomplished  if  maintained  under  a single  concept  of 
reference. 

The  UTAP  interface  definitions  are  designed  to  remain  constant  whatever  the  system  capability. 
The  UTAP  module  SERVICE  PROFILE  is  defined  to  provide  a scaling  mechanism.  For  each 
module,  the  SERVICE  PROFILE  describes  the  set  of  acceptable  UTAP  messages  and  data 
posting  capabilities. 

9.4.2  Timing 

The  timing  deadline  element  within  the  interfaces  will  be  done  in  a worst  case  manner.  The 
module  will  specify  the  worst-case  time  duration  that  it  can  receive  expects  new  message.  The 
modules  must  publish  this  value. 
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10  UTAP  Interface  Framework 


10.1  Interface  Types 

Not  every  interface  in  the  system  is  identical  conceptually.  Communication  interfaces  will  be 
categorized  into  the  following  groups:  1)  control  for  superior /subordinate  command-status  in- 
terfaces, 2)  query /response,  and  3)  peer-peer  event  synchronization. 

10.1.1  Control  Interface  Type 

A superior /subordinate  control  interface  type  applies  to  either  Sensor  or  Effector  (S/E)  behavior. 
Each  control  interface  is  part  of  a larger  chain  of  command.  The  objective  of  the  control  interface 
is  to  make  the  subordinate  do  something  for  the  superior.  The  subordinate  may  be  a simple 
slave  that  simply  obeys  the  orders  from  the  superior  and  translates  these  instructions  into 
some  machine  physical  format.  The  subordinate  may  contain  some  intelligence  and  add  some 
functional  transformation  of  which  it  is  the  expert.  See  Albus  [RCS]  for  more  insight  into  this 
command  and  control  theory.  The  UTAP  control  interfaces  will  adopt  a format  that  draws  from 
concepts  used  in  Servo  Control,  Programmable  I/O  chips  (PIO),  and  the  RS274D  language. 

The  UTAP  control  interface  mimics  servo  control  with  communication  from  a superior  to  a 
subordinate  module  treated  as  clocked  data  flow.  Of  note,  the  clocked  data  flow  may  only  last 
one  cycle.  The  clocked  data  flow  can  be  either  control  commands  or  status  readings.  For  control 
commands,  response  to  the  command  is  not  an  answer,  but  a servoing  action  and  status  report. 
For  status  readings,  response  is  either  a status  report  or  a sensor  interpretation. 

The  UTAP  control  interface  strategy  adopts  command,  status  and  mode  concepts  of  PIO  chips. 
A programmable  I/O  chip  (PIO)  has  operational  modes  and  parameters  that  must  be  initialized 
before  the  chip  is  functional.  Further  PIO  chips  allow  for  combinations  of  selection  modes. 
Selection  vectors  are  of  extreme  relevance  to  teleoperated  robotics  - for  example,  the  application 
of  force  control  in  one  axis,  while  using  position  control  in  the  other  axes.  UTAP  interface 
format  applies  the  PIO  programming  paradigm  requiring  to  first  initialize  the  subordinate  with 
the  appropriate  mode  and  control  parameters,  and  then  initiate  data  exchange.  The  ability 
to  combine  modes  and  load  parameters  creates  the  potential  for  errors  - either  over  or  under 
specifying  of  the  desired  control/sensing  strategy.  These  error  cases  have  associated  UTAP 
messages. 

The  blocking  sequence  and  synchronization  concept  of  RS274  were  used  and  extended  to  ac- 
commodate other  needs.  Although  the  UTAP  set  of  messages  for  BLOCK,  MACRO,  PLAN, 
and  EVENT  are  primitive  computer  language  constructs,  they  are  helpful  in  reducing  the  com- 
plexity of  an  interface.  Each  of  these  language  primitives  is  discussed  further  in  a later  section. 
The  BLOCK  messages  allow  for  synchronizing  concurrent  events.  The  MACRO  messages  allow 
a series  of  mode  and  parameter  settings  to  be  grouped  and  named.  This  allows  for  easy  con- 
text switches  among  operational  modes.  The  EVENT  messages  are  designed  to  augment  the 
BLOCK  messages  and  offer  more  robust  synchronization  of  operation.  The  PLAN  messages  are 
for  grouping  and  naming  a set  of  data  commands,  e.g.,  naming  a SAFE  motion  or  zone. 


25 


UTAP/WD  Standard  Interface  Environment 


10.1.2  Query-Response 

The  query  response  interface  is  more  closely  associated  with  state  knowledge  or  sensor  reading 
updates.  One  form  is  the  client/server  which  provides  a dialogue  or  question/answer  interface. 
The  client  asks  the  server  (in  many  cases  a subordinate  or  expert)  to  periodically  post  status  or 
state  information.  This  posting  can  go  to  the  superior  or  to  the  object  knowledge  module. 

Obviously,  one  doesn’t  want  every  conceivable  piece  of  system  state  information  flowing  through 
the  system  at  every  clock  cycle.  One  would  prefer  that  under  certain  circumstances,  relevant 
state  information  is  posted  in  the  timely  manner  desired.  For  example,  under  normal  operation, 
it  would  be  desirable  to  post  the  current  position  as  status  every  10  milliseconds.  For  gain 
tuning,  one  may  require  position  readouts  every  millisecond.  Under  maintenance  operation,  it 
might  be  desirable  to  post  the  current  position  and  encoder  readings  so  that  a problem  can 
be  tracked  down.  The  interface  must  be  flexible  and  allow  a range  of  state  information  to  be 
posted. 

The  ROUTE  data  structure  defined  below  was  intended  to  provide  a contextual-based  mecha- 
nism for  posting  state  information.  A module  would  receive  a get-info  query  and  then  post  the 
desired  state  information.  Depending  on  the  type  of  get,  the  state  information  could  be  posted 
once  or  periodically  updated.  The  same  mechanism  can  be  used  to  read  state  information  data 
from  the  Object  Knowledge  module. 

struct  ROUTE  { 

enua  { .STATUS  = 1 , 

_WRITE_T0_0I  = 2 , 

_READ_FR0N_0K  = 4 , 

_DELTA_0FFSET  = 8 , 

.ALTER  = 8 , 

} type; 
int  times; 

TIHE  npdate.period; 

}; 

The  range  of  potential  Object  Knowledge  attributes  is  formidable.  As  a basis,  the  following 
generic  attributes  have  been  designated.  These  attributes  cover  both  sensor /effector  control 
and  part  modeling  information.  The  baseline  UTAP  data  dictionary  of  parameters  is  given  in 
Figure  9. 


//  post  response  to  questioner 
//  posting  response  values  to  ok 
//  read  from  ok 
//  use  data  as  delta  offset 
//  alter  cmd  dx,dy ,dz,rx,ry,rz 
//  Bitmask  for  response  dest 
//  -1=  continuous,  0=stop,  1=1,... 
//  frequency  of  update 


acceleration 

jerk 

pressure 

attribute  Jiame 

luminance 

roughness 

clevice-units(e.g., encoder  Jicks) 

mass 

temperature 

flow 

material 

time 

force 

material  jiame 

torque 

geometry 

object  jiame 

velocity 

hardness 

orientation 

viscosity 

hiunidity 

pose 

others 

Jacobian 

position 

Figure  9 - Object  Knowledge  Parameter  List 


The  concept  of  max,  min,  avg,  real  (current),  desired,  last,  and  timed  historical  reading  (e.g., 
2nd  to  last)  will  be  used  as  attribute  modifiers  within  the  message  interface.  Thus,  one  can 
get  and  post  desired  position  and  real  position.  The  attribute  in  this  case  is  position,  and  the 
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modifiers  are  desired  and  real. 


10.1.3  Peer-to-Peer 

Peer-to-peer  may  be  necessary  for  synchronization  of  modules.  Cases  such  as  awaiting  the  com- 
pletion of  fixturing  by  an  operator  or  awaiting  the  completion  of  a tool  change  before  moving 
are  examples  of  synchronization  events.  Synchronization  of  this  type  can  be  avoided  by  syn- 
chronizing events  at  a higher  level  in  the  architecture.  We  will  assume  this  can  be  done,  and 
will  not  address  peer-to-peer  synchronization  within  the  UTAP  at  this  time. 

10.2  Syntactics 

Interfaces  will  have  the  following  naming  conventions.  The  C preprocessor  directive  ^define 
will  be  used  to  define  message  names  and  assign  a unique  system  numeric  id.  Each  mes- 
sage name  will  be  in  capital  letters.  Each  message  name  will  be  prepended  by  a US  for 
Unified  System.  The  US  part  will  be  followed  by  the  module  name  - unless  the  message  is 
a generic  message  - e.g.,  US-ModuleName.  Then,  the  actual  message  name  will  follow  - e.g., 
US_ModuleName_MessageName.  The  data  type  naming  convention  will  use  lower-case  letters 
and  in  general  merely  append  a _msg_t  to  signify  message  type,  e.g., 
us_modulename_messagename_msg_t. 

Table  2 gives  a summary  table  of  contents  for  the  message  numbering. 

Annex  H summarizes  the  set  of  messages.  Within  Annex  H.3,  the  file  utapJnterfaces.h  contains 
the  message  id  and  associated  message  structure.  Below  are  two  examples  from  this  file.  The 
presentation  style  has  a ^define  message  id  preceding  each  message  structure.  So  far,  there  are 
approximately  250  messages. 

•define  US.HALT  102 
struct  U8_halt_m8g_t  { 
int  asgid; 

} ; 

•define  US_AXIS_SERVO_LOAD_PID_GAIIS  210 
struct  u8_axis_servo_load_pid_gains_m8g_t  { 
int  msgid ; 
double  p; 
double  i; 
double  d ; 

}; 


10.2.1  Variable  Length  Arrays  Resolution 

One  of  the  difficulties  that  arises  defining  interfaces  concerns  the  problem  of  handling  variable 
length  arrays.  Unless  one  rejects  the  notion  of  flexibility,  an  interface  should  not  preordain  a 
fixed  array  size  for  any  interface.  One  would  find  pzissing  7 joint  values  to  a 3-ajds  mill  less  than 
intuitive.  Generally,  array  pointers  are  used  to  overcome  this  problem. 

The  UTAP  interfaces  shall  use  the  following  strategy:  1)  if  necessary,  declare  the  degrees  of 
freedom  as  a mode  parameter,  and  2)  reference  data  array  information  indirectly  into  a heap 
mechanism  (i.e.,  a zone  of  memory  in  which  multi-linked  nodes  of  variable  size  are  allocated)  that 
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MESSAGE 


msg  id 

— pos  * 

— vel  * 

pos  1 

pos  2 

pos  3 

pos  4 

pos  5 

pos  6 

— ► 

vel  1 

vel  2 

vel  3 

vel  4 

vel  5 

vel  6 

} 


HEAP 


Figure  10  - Heap  Applied  to  Message  Handling 


follows  the  message.  Figure  ??  illustrates  the  concept  when  passing  an  array  of  joint  positions 
and  velocities  to  a 6 DOF  robot.  Should  one  pass  to  a 3D0F  machine  tool,  the  message  would 
still  have  the  position  and  velocity  contents,  but  the  heap  would  only  contain  three  elements  for 
each  field. 

Overall,  the  message  structure  can  be  represented  with  the  following  equation: 

MESSAGE  = HEADER  + CONTENT  + HEAP  (3) 

where  the  HEADER  contains  protocol  or  “how-to”  specific  information,  the  CONTENT  defines 
“what-is”  or  the  message  information,  and  the  HEAP  contains  the  variable-length  data  contents. 

10.3  Semantic  Meaning 

At  this  point,  the  exact  semantic  meaning  of  many  of  the  UTAP  messages  has  not  been  explicitly 
spelled  out  in  English.  For  now,  the  intent  and  meaning  of  UTAP  API  messages  should  be 
apparent  from  the  message  name. 

One  simplification  was  the  use  a special  keywords  and  a keyword  convention  to  specify  the 
semantic  intent.  The  keyword  convention  provides  consistent  message  naming  which  leads  to 
easier  comprehension.  The  UTAP  naming  convention  follows  a generic  flow  plan  that  categorizes 
control,  data,  parameter  and  mode  message  traffic.  Figure  8 illustrates  the  flow  of  information 
and  the  naming  convention  relationships.  The  flow  of  traffic  is  divided  into  1)  control  sequence, 
2)  modes,  3)  algorithm  selections,  4)  parameter  settings,  5)  real-time  data,  6)  information 
requests  and  7)  information  responses.  The  information  flow  is  equivalent  for  superior  as  well  as 
subordinate  connections,  except  that  there  can  be  multiple  instances  of  subordinate  information 
flow.  Although  conceptually  demarcated,  the  information  flow  would  most  likely  require  only 
one  or  two  connections  to  the  superior,  and  to  each  subordinate  - one  for  command  and  possibly 
another  for  status.  (The  bi-directional  arrows  for  many  of  the  categories  was  used  to  convey  the 
notion  that  one  wire  is  for  commands  and  the  other  wire  is  for  errors  or  acknowledgment.) 

The  naming  convention  uses  keywords  to  delineate  mode/goal/state  information.  These  key- 
words are  embedded  within  the  messages  to  categorize  the  semantic  interpretation  of  a message. 
The  keywords  are  grouped  by  type: 

- MESSAGING  (i.e.,  BLOCK,  MACRO,  PLAN,  EVENT,  SELECTION) 

- SEQUENCING  CONTROL:  generics  (i.e.,  STARTUP,  SHUTDOWN,  ENABLE,  DIS- 
ABLE, etc.) 
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- MODALITY:  USE,  START,  STOP,  COMPUTE 

- PARAMETRIC:  LOAD,  INCREMENT,  SELECT 

- DATA  COMMAND:  SET,  ADJUST,  GET 

- STATUS:  POST 

Annex  C provides  a module  by  module  profile  of  the  UTAP  flow  plans.  These  profiles  are  blank 
templates  that  can  be  used  to  specify  the  requirements  of  a desired  system.  These  profiles 
provide  a complete  list  of  all  the  potential  inputs  and  outputs  of  a module.  The  annex  fists 
input  and  output  entries  by  flow  category.  Some  categories  have  cross-references  to  other  flow 
plans. 


10.3.1  Control  Mode  Sequencing 

Most  module  control  sequencing  is  done  with  generics.  The  sequencing  generics  are  grouped 
by  levels  of  operation  - module  operation,  sensor /effector  operation,  and  software  operation. 
STARTUP,  RESET  and  SHUTDOWN  are  module  power-cycle  sequencing  operations.  EN- 
ABLE DISABLE,  HOLD,  and  ESTOP  are  sensor /effector  power  sequencing  operations.  INIT, 
START,  STOP,  PAUSE,  HALT,  ABORT,  are  software  basic  program  sequencing  commands. 
BEGIN_SINGLE_STEP,  NEXT^INGLE-STEP,  CLEAR_SINGLE_STEP, 

MARK-BREAKPOINT  and  MARK-EVENT  are  generic  keywords  that  deal  with  more  ad- 
vanced program  execution.  The  only  generic  not  commonly  found  is  MARK-EVENT  which  is 
used  as  a reference  marker  for  an  EVENT  primitive. 

A typical  sequencing  operation  consists  of  the  following  steps.  First,  the  control  sequence  key- 
word STARTUP  brings  the  module  into  a safe  state.  Second,  one  programs  the  module  with 
the  appropriate  control,  mode  and  parametric  settings.  Once  programmed,  the  sensor /effectors 
are  powered  on  with  the  control  sequence  keyword  ENABLE.  Finally,  the  software  program 
is  executed  by  issuing  the  control  sequence  keyword  START.  At  this  point,  clocked  data  flow 
commences. 

10.3.2  Keywords 

For  mode  messages,  the  words  USE,  START,  STOP,  COMPUTE  are  used  to  convey  the  notion 
of  parameter  setting  or  algorithmic  selection.  The  word  LOAD  and  INCREMENT  are  used  for 
parameter  values.  The  words  SET,  GET,  and  ADJUST  are  used  to  denote  a commanded  action. 

USE: 

The  USE  keyword  conveys  the  notion  of  modal  or  a mutually  exclusive  algorithm  selection. 
Modal  commands  stay  in  effect  until  cancelled.  The  COMPUTE  keyword  is  a synonym  for 
the  USE  keyword  and  exists  since  some  messages  aren’t  as  apparent  with  the  USE  keyword, 
e.g.,  USE-GREY-VALUE  versus  COMPUTE-GREY-VALUE. 

START/STOP: 

It  was  decided  that  the  UTAP  interfaces  must  support  simultaneous  multiple  actions.  The 
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terms  START  and  STOP  convey  the  notion  for  initiating/terminating  simultaneous  or  mul- 
tiple selections.  Thus,  one  can  START  one  or  multiple  algorithms  when  necessary.  Then,  the 
command  STOP  is  used  to  discontinue  the  algorithm.  For  example,  gravity  compensation  can 
be  used  to  augment  many  servo  algorithms.  Thus  START -GRAVITY-COMPENSATION 
remains  in  effect  until  terminated  with  a STOP-GRAVITY-COMPENSATION. 

LOAD,  INCR(EMENT),  ZERO: 

The  LOAD  keyword  signifies  parametric  value  setting.  Load  implies  that  one  presets  a 
parameter  during  initialization,  or  can  dynamically  change  the  value  during  clocked  data 
updates.  For  example,  velocity  can  be  fixed  or  dynamically  updated  with  each  motion. 
The  INCREMENT  keyword  is  used  to  denote  an  incremental  (or  decremental)  update  to  a 
parameter.  For  example,  INCREMENT  is  useful  for  relative  increases  of  desired  velocity. 
INCR  may  be  used  as  shorthand  for  INCREMENT.  The  ZERO  keyword  means  to  use  the 
current  reading  as  the  origin.  Thus,  ZERO  is  often  used  to  initialize  a relative  coordinate 
frame.  The  SELECT  keyword  is  used  with  a parameter  setting  for  choosing  from  a set  of 
established  parameters. 

SET,  ADJUST: 

The  SET  and  ADJUST  keyword  signify  instructional  command  messages.  These  messages 
provide  a goal  for  the  module  to  achieve.  The  verb  SET  signifies  a goal  for  the  subordinate 
to  attain  or  maintain..  The  verb  ADJUST  is  used  to  convey  incremental  or  decremental 
changes.  Such  changes  are  useful  for  tuning  the  commanded  goal  state.  Conceptually,  this 
is  equivalent  to  moving  to  a position,  zeroing  the  position  as  a relative  position  and  then 
moving  a small  relative  offset  - but  ADJUST  is  conceptually  simpler.  A joystick  -f /-  button 
interface  is  an  example  of  interface  that  requires  the  ADJUST  concept  where  positional 
change  is  relative. 

GET: 

The  verb  GET  is  used  to  initiate  a response  - either  a status  report,  or  a sensor  reading. 
GET  has  a corresponding  response  POST.  The  GET  is  part  of  the  Query-Response  interface 
connection.  Each  GET  message  contains  routing,  attribute  and  modifier  information.  For 
example,  the  generic  message  US-GET-VALUE  requires  routing,  an  attribute  and  a modifier. 

tdefine  US-GET-VALUE  S5 
struct  us-get-value-msg-t  { 
int  msgid ; 

ROUTE  r; 

Attribute-t  items; 

Nodifier-t  modifiers; 

}; 


The  routing  information  (i.e.,  ROUTE)  describes  the  return  destination  of  the  response. 
The  Attribute-t  entry  contains  the  query  identifier.  For  common  attributes,  the  attribute 
information  is  explicit  to  the  message  name,  e.g.  US-ATTRIBUTE-GET_POSITION.  The 
Modifier-t  describe  state  information  about  the  attribute,  e.g.  real,  desired,  max,  min,  etc. 
GET-LIST  is  available  to  query  information  about  data  collections. 
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POST: 

The  verb  POST  is  used  to  convey  the  notion  of  an  output  reading.  This  output  reading 
could  be  either  a status  report,  or  a sensor  reading.  Further,  the  output  reading  could  be 
posted  to  the  superior  or  to  the  Object  Knov^'ledge  module.  Within  the  GET,  a field  is  set 
aside  to  designate  the  destination  of  the  subsequent  POST  - either  to  the  superior.  Object 
Knowledge  module  or  both.  The  POST  messages  use  this  information  for  return  routing. 

INPUT/OUTPUT: 

Interfaces  that  support  query  or  posting  services  and  provide  the  same  interface  to  numerous 
modules  wiU  adopt  the  following  naming  convention:  for  input  and  output,  append  either 
JNPUT  or  -OUTPUT  to  the  server  module  name,  e.g.,  OK  JNPUT. 


10.3.3  Designating  Subordinate  Selections 

The  UTAP  architecture  allows  multiple  subordinate  modules  to  be  controlled  by  one  superior 
module.  In  Figure  3 for  example,  the  Task  Level  Control  module  is  controUing  6 submodules 
- pairs  of  robot,  tool  and  sensor  modules.  Because  of  the  existence  of  alternatives,  a robot 
command  issued  to  the  Task  Level  Control  can  be  ambiguous  as  to  which  robot  the  command 
is  intended.  Additionally,  generic  messages  such  as  LOAD-SAMPLING-RATE  are  applicable 
across  many  of  the  subordinate  modules.  Thus,  an  interface  mechanism  is  required  to  resolve  this 
confusion.  Naming  resolution  of  identical  module  types  was  addressed  within  the  configuration 
section.  This  section  describes  a message  set  to  enable  selections. 

The  generic  messages  GET,  POST,  USE-SELECTION  and  USE_AXIS-MASK  are  UTAP  pro- 
gramming primitives  enabling  the  interface  to  specify  selections.  The  GET-SELECTION  is  a 
primitive  to  request  a read  of  the  configuration  table,  and  subsequent  mapping  of  a symbolic 
name  into  a system  id  number.  The  POST-SELECTION  returns  the  id  number.  The  message 
USE-SELECTION  and  appropriate  numeric  id  designates  the  destination  of  the  future  messages. 
USE-SELECTION  is  a modal  command  and  stays  in  effect  until  changed.  USE_AXIS-MASK 
is  a programming  convenience  for  modules  with  multiple  servos  under  coordinated  control.  The 
AXIS-MASK  message  contains  a bitmask  enumerating  the  selected  axis. 

The  following  code  illustrates  the  use  of  the  SELECTION  message  set.  First,  one  does  the  sym- 
bolic mapping  with  GET-SELECTION  to  retrieve  the  appropriate  ids  for  robotl  and  robot2. 
(It  is  assumed  that  the  Object  Knowledge  modiile  responds  with  a POST-SELECTION,  but 
is  hidden  in  this  example.)  Then  one  alternates  between  robot  selections  to  describe  the  co- 
ordinated motion.  The  addition  of  the  BEGIN-BLOCK  and  END-BLOCK  message  primitives 
illustrates  a mechanism  to  do  concurrent  motion  control. 

robotl  = GET-SELECTIOI("TLC:A:ROBOT:A") ; 
robot2  = GET-SELECTI0I("TLC:A:R0B0T:B") : 
robots  = GET_SELECTI0I("TLC:B:R0B0T:A'*)  : 

BEGII-BLOCKO  ; 

USE-SELECTIOKrobotl) ; 

SET_P0SITI0I(lO. 0,20. 0,10. 0,0.0,  90.0,  0.0); 

USE-SELECTI0I(robot2) ; 

SET-P0SITI0I(2O. 0,20. 0,10. 0,0.0,  90.0,  0.0); 

EID-BLOCEO  ; 

The  SELECTION  message  set  is  intended  for  multiple  subordinates  that  are  in  need  of  pro- 
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grammatic  control.  It  may  be  an  option  of  the  system  to  let  the  module  itself  designate  the 
recipient  of  a set  of  messages.  For  example,  suppose  a system  has  a right  and  left  arm  that  are 
functionally  equivalent,  then  selection  of  the  left  or  right  subordinate  can  be  context-driven  or 
situation-dependent.  If  the  superior  is  privy  to  some  future  knowledge  that  impacts  the  selection, 
it  may  select  the  best-fit.  Otherwise,  the  subordinate  could  select  a first-fit  or  random-fit. 


10.3.4  Synchronization 

Control  systems  require  synchronization  of  devices  within  the  system.  For  example,  one  would 
like  for  a tool  change  to  complete  before  initiating  the  next  tooling  motion.  Another  possibility 
is  that  one  desires  that  a series  of  motions  be  treated  as  one  continuous  motion  without  any 
interruption  - or  some  dwell  could  occur. 

Within  the  UTAP  framework,  synchronization  is  achieved  with  BEGIN.BLOCK  and 
END-BLOCK  generic  messages.  This  construct  is  similar  to  the  block  concept  in  RS274.  Mes- 
sages that  arrive  between  the  BEGIN  and  END  BLOCK  messages  are  treated  as  a unit.  It  is 
assumed  that  the  receiving  module  understands/describes  how  a set  of  operations  are  synchro- 
nized. The  BLOCK  set  of  messages  is  especially  valuable  for  coordinating  actions  within  the 
Parent  Task  Program  Sequencer  module  in  the  UTAP. 

The  EVENT  set  of  messages  provides  event-driven  command  sequencing.  This  is  useful  for 
operations  that  are  sequenced  to  begin  or  end  at  some  specified  time  within  a BLOCK  of  com- 
mands, or  begin  or  end  when  a concurrent  operation  reaches  some  state.  The  BEGIN -EVENT 
is  embedded  within  a BLOCK  construct  and  provides  for  an  event  to  occur  within  the  BLOCK 
either  FROM-START,  FROM-END,  ERROR,  or  AT  a specified  time  t.  The  ERROR  event 
would  call  the  currently  loaded  SAFE  motion  plan  should  some  limit  or  error  be  encountered. 
(See  following  section  for  more  details  on  this  concept.)  It  is  hoped  to  allow  further  exception 
handling  and  event  triggered  callbacks  within  the  EVENT  primitive  at  some  future  point  in 
time. 

10.4  Extensibility 

The  ability  to  broaden,  shrink,  or  advance  a system’s  functionality  is  required  by  the  UTAP 
architecture  and  must  be  supported  by  the  interfaces.  This  flexibility  and  extensibility  must 
be  achieved  through  explicit  mechanisms.  Extensibility  within  UTAP  Interface  Framework 
features  1)  state  context  and  parameter  aggregating  and  naming,  and  2)  scalable  and  3)  seamless 
integration  of  sensors. 


10.4.1  State  Context  Naming 

The  ability  to  aggregate  and  name  a set  of  messages  based  on  some  state  context  information 
can  greatly  simplify  programming.  One  of  the  small  enhancements  to  the  messaging  system  was 
the  inclusion  of  the  MACRO  and  PLAN  set  of  messages. 

The  MACRO  set  of  commands  allow  one  to  group  and  name  a set  of  parameter  messages.  One 
sends  a BEGIN -MACRO  with  a name,  a set  of  parameter  messages  and  then  the  END-MACRO 
message  to  define  the  macro.  One  uses  the  USE-MACRO  command  to  invoke  these  parameter 
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settings.  Below  is  an  example  set  of  messages  that  may  be  grouped  to  describe  a fragile  or  rigid 
parameter  setting.  Then,  depending  on  the  type  of  object,  one  selects  the  correct  parameter 
context.  For  china,  use  delicate.  For  steel,  use  rigid. 

US_BEGII_MACRO  (requires  name,  e.g.,  fragile  or  rigid) 

US_L0AD_TLC_D0F 

US_LOAD_TLC_FEED_RATE 

US_LOAD_TLC_TRAVERSE_RATE 

US_LOAD_TLC_COITACT_FORCES 

US_LOAD_TLC_STIFFIESS_PARAMETERS 

US_LOAD_TLC_JOIIT_GAII_THRESHOLD 

US_LOAD_TLC_JOIIT_SIIGULARITY_THRESHOLD 

EID.NACRO 


USE.MACRO  fragile 


Similarly,  the  PLAN  set  of  commands  allow  one  to  aggregate  and  name  a set  of  motions.  This 
feature  would  be  useful  if  one  wanted  to  name  a “SAFE”  motion  zone  as  a fallback  motion  in 
case  of  an  error. 


10.4.2  Scaling  Control  Dimensions 


One  peril  involving  generic  interfaces  is  the  requirement  to  satisfy  a broad  performance  range. 
For  example,  some  systems  can  provide  a cost-effective  solution  with  minimal  complexity  and 
were  not  intended  for  more  sophisticated  applications.  One  cannot  require  a simple  but  cost- 
effective  module  to  accommodate  the  entire  realm  of  interface  possibilities.  To  be  effective,  the 
ability  to  scale  the  interface  is  needed. 


Scaling  within  the  Task  Level  Control  module  implies  that  its  generic  interface  must  accom- 
modate simple  position  control  as  well  as  hybrid  force-control  with  multi-device  sensor  fusion. 
Previous  discussion  illustrated  the  concept  of  scaling  mode  and  parameter  selection  vectors. 
This  section  will  discuss  the  use  of  option  levels.  The  following  message  illustrates  the  levels  one 
can  have  when  defining  the  trajectory  kinematic  ring  [BACKES2]. 


fdefine  US_TLC_USE_KIIEHATIC_RIIG_P0SITI01IIG_M0DE  626 
struct  us_tlc_use_kinomatic_ring_in8g_t  { 
int  id ; 


}; 


Neasurement.units.type  units; 


enun  { BASE 

= 

0x0000001 

TOOL 

= 

0x0000002 

SEISOR.FUSIOI 

= 

0x0000004 

//  RHS 

DELTA 

= 

0x0000010 

OBJECT 

= 

0x0000020 

OBJECTBASE 

= 

0x0001000 

0BJECT0FFSET2 

= 

0x0002000 

0BJECT0FFSET3 

= 

0x0003000 

0BJECT0FFSET4 

= 

0x0004000 

} ring.mask ; 

A selection  mask  is  provided  to  allow  the  sophistication  of  the  Task  Level  Control  module  to 
vary.  The  selection  mask  provides  for  one  to  define  levels  of  positioning  control  - from  simple 
position  updates,  to  allowing  sensor  fusion  and  specifying  transform  models  for  the  base,  tool, 
object  base.  This  range  of  specificity  allows  a broader  range  of  modules  to  use  the  same  generic 
interface  without  unnecessary  expectations  of  a simpler  control  module. 
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10.4.3  Integration 

An  extension  that  one  might  desire  is  the  ability  to  do  on-line  configuration  and  assignment  of 
communications.  For  example,  when  you  add  a new  sensor  to  your  system,  and  you  may  wish 
to  pump  this  data  into  an  existing  module.  This  can  be  especially  difficult  if  real-time  readings 
impact  the  control  behavior.  How  do  you  accompUsh  this  task?  Generally,  one  would  have  a 
sensor  fusion  hook  that  allows  sensors  to  pump  readings  into  the  sensor  fusion  slot. 

One  would  desire  the  abihty  to  say  to  a subordinate,  “I  want  you  to  input  readings  from  the 
so-and-so  sensor  and  use  this  reading  to  calculate- an-offset/postmultiply /alter /delta- frame  and 
modify  the  nominal  goal  action  into  an  altered  goal  action.”  The  use  of  the  MACRO,  GET 
message  with  the  USE-SELECTION  message  enables  this  capability.  Within  the  GET  message, 
one  specifies  the  routing  information  as  a delta  offset  destination.  Thus,  the  module  uses  a sub- 
ordinate reading  to  modify  its  nominal  goal  with  a delta  offset.  The  following  code  demonstrates 
this  concept.  The  code  embeds  a SELECTION  and  GET  message  within  a MACRO  message 
that  will  instruct  a subordinate  to  use  one  of  its  subordinates  readings  as  a delta  offset  value. 

us_begin_macro("Sen8or  Integration") ; 

u8_u8e_8election(us_get_8eloction("R0B0T. A;SEIS0R.B")) ; 
us_get_value(ROUTE . _DELTA_0FFSET , 

-1 , //  forever 

.002,  //  every  2 milliseconds 

0);  //  in  delta  offset  location  1 

us_end_macro("Sensor  Integration") ; 

us_ase_select ion (u8_get_8elect ionC'ROBOT . A" ) ) ; 
us-Use-macro("Sensor  Fusion"); 


10.4.4  New  Messages 

The  UTAP  interfaces  define  a great  many  messages.  Yet,  it  would  be  impossible  to  anticipate  and 
explicitly  enumerate  every  possible  control  and  sensing  algorithm  and  parameter.  For  example, 
suppose  a better  servo  control  algorithm  is  developed,  how  will  the  interface  permit  the  selection 
of  this  algorithm?  Further,  suppose  an  additional  compensation  parameter  could  be  specified 
within  the  servo  control.  How  will  the  system  adapt  to  the  additional  parametric  capability? 

Although  it  is  hoped  that  the  current  set  of  messages  do  indeed  satisfy  the  needs  of  the  UTAP 
task  scenarios,  a mechanism  is  required  for  extending  the  scope  of  the  interfaces.  There  exist 
many  possibilities  to  extending  the  message  set.  Providing  new  definition  construct  (such  as 
/‘name’ ...  def  in  Postscript)  within  the  interface  language  is  one  solution  but  greatly  complicates 
the  interface.  For  statically  defined  and  published  interfaces,  the  extensibility  problem  is  inherent 
since  the  interface  language  does  not  provide  general  programming  constructs.  Without  general 
programming  constructs,  supporting  the  requirements  of  portability  and  extensibihty  is  difficult. 

Adhering  to  a simple  strategy  for  now,  the  current  UTAP  solution  is  to  provide  slot-holder 
messages  to  handle  new  messages.  For  comparison,  the  part  description  language  RS274  pro- 
vides macro  slot  holders,  M80-M89,  as  a means  of  customization  in  a constrained  manner. 
The  UTAP  extension  will  use  the  letters  “EXT”  to  signify  non-standard  message  extension. 
The  extension  messages  include  US-USE_EXT_ALG0RITHM,  US_LOAD_EXT_PARAMETER, 
US-SET_EXT_DATA_VALUE,  US-GET-EXT-DATA_VALUE 

and  US-P0ST_EXT_DATA_VALUE.  Each  message  uses  a numeric  id  to  specify  the  extension 
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instance.  For  example,  id=l  specifies  extension  one,  id=2  specifies  extension  two,  etc. 

The  flexibility  to  add  new  messages  comes  at  a cost.  Complete  interoperability  can  no  longer  be 
guaranteed.  For  example,  RS274-deflned  parts  that  use  the  M80-89  macros  contain  implemen- 
tation specific  descriptions.  These  macros  are  rarely  portable.  UTAP  extensibility  will  allow 
for  technology  to  evolve,  so  that  if  an  algorithm  or  feature  extension  becomes  popular  enough 
- so  that  more  than  one  vendor  is  supporting  it  - then  it  can  be  transformed  into  a “regular” 
supported  message  in  a later  revision  of  the  UTAP  interfaces. 
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Table  1 - Module  Classification 


Module  Class 

Type 

Examples 

01 

POS  Joystick 

Force  Reflecting  Joystick 
Pendant 

Panel 

Windows 

SpacebaU 

6D0F  F /R  Joystick 

PIO:  Screen,  Buttons,  Dials,  Switches 
X-Windows,  Windows 

OM,  OC,  OK 

TD,  TK,  TDS 

Teach 

Scripted 

Programmable 

Record/ Playback  Motions 

Save/Load  Parameters,  Scripts 

Save /Load  Program 

TPS 

Manipulation 

Navigation 

Tooling 

Machining 

Assembly 

(Not  covered) 

TPS:  Transport 

Teleop 

Guided 

Autonomous 

Lift 

Tracked 

overhead  gantry 

TPS:  Tooling 

Contact 

Non-contact 

Finishing 

Spraying 

TPS:  Machining 

Horizontal 

TLC:  AXIS-SERVO 

SLM 

*SCARA 

♦GANTRY 

♦STEWART.PLATFORM 

Serial  Link  Manipulator 

TLC:  SENSOR 

FTS 

IMAGE 

PROBE 

♦SWITCH 

JR3  force  torque  sensors 
camera  images 

LVDT 

beam-break,  open/close  gripper 

TLC:  TOOL 

SPRAY 

FINISH 

♦GRASP 

♦SQUEEZE 

coolant,  paint,  wash 

sand,  grind,  chamfer,  debur  - compliant 

grasp 

squeeze 
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Table  2 — Message  Type  Identification  Table  of  Contents. 


GENERIC: 

101  - 199 

ERROR: 

-100  - -200 

REMOTE 

AXIS-SERVO: 

200  - 299 

TOOL: 

300  - 399 

SENSOR: 

400  - 499 

PIO: 

500  - 599 

TLC: 

600  - 699 

DB: 

700  - 799 

VS: 

800  - 899 

LOCAL 

TDS: 

1000  - 1099 

TK: 

1100  - 1199 

TRD: 

1200  - 1299 

FTPS: 

1300  - 1399 

TPS: 

1400  - 1499 

01: 

1500  - 1599 

OK: 

1600  - 1699 

SGD: 

1700  - 1799 

ADS: 

1800  - 1899 

SS: 

2000  - 2099 
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Annex  B 

(normative) 

Component  Analysis 


The  National  Center  for  Manufacturing  Sciences  sponsorship  of  the  Next  Generation  Controller 
project  which  defined  the  Specification  for  an  Open  System  Architecture  Standard  (SOSAS) 
document  [SOSAS].  This  document  provides  an  overview  of  philosophy  and  structure  of  the 
NGC.  The  SOSAS  describes  a reference  architecture  that  is  comprised  of  primitive  components. 
From  the  reference  architecture  an  application  architecture  is  constructed  that  captures  the  func- 
tionality of  the  end  systems  at  an  abstract  level.  The  selection  of  implementation  components 
determines  the  final  system. 

Each  component  is  an  abstract  encapsulation  of  funcionality 

B.l  Application  Architecture 
AC  1 - Object  Modeling: 

RESPONSIBILITY:  Object  modeling  provides  for  modeling  of  objects.  This  includes 
initial  off-line  description  of  objects  and  run-time  model  building. 

INPUT:  Object  types,  attributes,  sensor  data,  operator  input 

OUTPUT:  Updated  object  types,  attributes,  sensor  data,  operator  input 

AC  2 - Object  Calibration: 

RESPONSIBILITY:  Calibration  of  an  object’s  actual  properties,  e.g.,  position 
INPUT:  Object  initial  calibration  properties 
OUTPUT:  Updated  object  calibration  properties 

AC  3 - Trajectory  Description: 

RESPONSIBILITY:  Specify  a trajectory  for  use  in  an  application  program 

INPUT:  Path  information  such  as  starting  and  end  points,  continuous  inputs  such  as  from 
a hand  controller,  preferred  path  segments 

OUTPUT:  Trajectory  for  insertion  into  task  program 
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AC  4 - Object  Knowledgebase: 

RESPONSIBILITY:  Store  information  about  objects  in  the  task  environment  including 
geometry  and  task  information 

INPUT:  Object  information 

OUTPUT:  Object  information 


AC  5 - Operator  Input  Devices: 

RESPONSIBILITY:  Transform  operator  input  information  into  data  for  software  mod- 
ules and  provide  feedback  to  operator  via  input  mechanisms 

INPUT:  Operator  interaction  and  feedback  data 

OUTPUT:  Operator  input  data  to  system  modules,  e.g.,  keyboard,  audio,  and  handcon- 
t roller 

AC  6 - Status  & Graphical  Display: 

RESPONSIBILITY:  Display  system  status  including  geometry,  sensor  data  and  task  ex- 
ecution status 

INPUT:  Object  status,  task  execution  status,  system  status 

OUTPUT:  Status  and  geometry  displays  to  operator,  e.g.,  task  execution  status  and  geo- 
metric graphical  display 


AC  7 - Task  Description  Supervision: 

RESPONSIBILITY:  Interactive  task  sequence  (application  program)  generation  and  run- 
time interaction  with  operator  for  sequencing  and  sequence  modification 

INPUT:  Information  to  generate  application  programs,  e.g.,  task  commands,  macros,  task 
sequences,  object  information,  trajectories 

OUTPUT:  Application  program  including  task  programs 


AC  8 - Analysis  Sz  Diagnosis: 

RESPONSIBILITY:  Analyze  and  diagnose  task  execution  status 
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INPUT:  Task  execution  status  and  task  information  on  what  and  how  to  monitor 
OUTPUT:  Execution  status  and  execution  control  commands  such  as  stop 

AC  9 - Subsystem  Simulation: 

RESPONSIBILITY:  Provide  a simulation  of  the  task  execution 
INPUT:  Task  program  commands 
OUTPUT:  Simulated  subsystem  control  data 

AC  10  - Task  Knowledgebase: 

RESPONSIBILITY:  Provide  task  sequence  building  blocks  such  as  macro  commands  and 
sequences 

INPUT:  Requests  for  commands  or  command  types 

OUTPUT:  Macro  commands  and  sequences  with  unbound  parameters 

AC  11  - Subsystem  Task  Program  Sequencing: 

RESPONSIBILITY:  Sequence  the  subsystem  task  program  commands 

INPUT:  Task  programs  and  execution  status 

OUTPUT:  Task  level  control  commands  and  execution  status 

AC  12  — Parent  Task  Program  Sequencing: 

RESPONSIBILITY:  Sequence  the  parent  task  program  commands 
INPUT:  Parent  task  program  and  execution  status 
OUTPUT:  Next  command  to  execute 

AC  13  - Subsystem  Control: 
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INPUT:  Task  program  commands  and  command  sequences  and  data  from  sensors,  tools 
and  mechanisms 

OUTPUT:  Status  and  commands  to  sensors,  tools  and  mechanisms 

AC  14  - Sensor  Control: 

RESPONSIBILITY:  Provide  control  of  a sensor 

INPUT:  Sensor  commands  and  raw  sensor  data 

OUTPUT:  Processed  sensor  data  and  low  level  sensor  commands 

AC  15  - Sensing: 

RESPONSIBILITY:  Gather  raw  sensor  data 
INPUT:  Low  level  sensor  commands 
OUTPUT:  Raw  sensor  data 

AC  16  - Tool  Control: 

RESPONSIBILITY:  Control  a tool 
INPUT:  Tool  control  commands  and  tool  status 

OUTPUT:  Processed  tool  data  and  low  level  tool  commands  such  as  analog  voltage 

AC  17  — Tool  Motion: 

RESPONSIBILITY:  Generate  the  tool  motion  such  as  by  driving  a motor 
INPUT:  Low  level  tool  commands  such  as  analog  voltage 
OUTPUT:  Tool  status 

AC  18  - Robot  Servo  Control: 

RESPONSIBILITY:  Provide  joint  level  servo  control 
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INPUT:  Robot  configuration  commands  and  status 

OUTPUT:  Joint  status  and  low  level  robot  joint  commands  such  as  voltage  and  status 


AC  19  - Robot  Motion: 

RESPONSIBILITY:  Generate  the  joint  motion  of  the  robot  such  as  by  driving  a motor 
INPUT:  Low  level  robot  joint  commands 
OUTPUT:  Robot  joint  status 


AC  20  - Virtual  Sensor: 

RESPONSIBILITY:  Compute  information  as  if  it  came  from  a real  sensor,  but  using 
available  data,  such  as  for  multiple  sensor  fusion 

INPUT:  Sensor  commands  and  data 

OUTPUT:  Computed  viitual  sensor  data 

B.2  Hardware  Architecture 

HC  1 - Interface  Controller: 

RESPONSIBILITY:  The  interface  controller  is  the  computer  which  the  operator  uses  to 
interact  with  the  application  programs.  The  supported  interface  may  be  simple,  e.g.,  ascii 
inputs  and  outputs,  or  more  complex,  e.g.,  iconic  interface  with  multiple  input  devices.  The 
actual  input  devices  such  as  voice  input/output  and  hand  controller,  are  treated  as  individual 
devices  with  their  control  programs. 

INPUT:  Inputs  from  operator  input  devices  and  status  from  task  controller 
OUTPUT:  Status  to  operator,  e.g.,  visual  or  audio,  and  task  commands  to  task  controller 


HC  2 - Task  Controller: 
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INPUT:  Task  commands  from  the  interface  controUer  and  status  from  the  device  controllers 
OUTPUT:  Commands  to  the  device  controllers  and  status  to  the  interface  controUer 


HC  3 - Device  Controller: 

RESPONSIBILITY:  The  device  controUer  hardware  receives  the  device  commands  from 
the  task  controUer  hardware.  These  commands  wiU  vary  depending  on  the  configuration 
(profile)  of  the  controUer.  There  are  various  options  for  the  hardware  profiles.  The  device 
controUer  could  be  a microprocessor  card  which  has  servo  control  software  on  it.  It  could 
take  joint  positions  as  input  commands  and  output,  to  the  device  ampUfier,  analog  or  digital 
commands  such  as  velocity  or  torque.  Parameters  for  the  servo  control  wiU  also  be  com- 
municated to  the  servo  control.  This  same  functionality  could  also  be  provided  by  buying 
a motion  control  card.  For  sensors,  the  device  controUer  converts  commands  to  low  level 
sensor  signals.  When  reading  the  sensor,  the  device  controUer  processes  the  sensor  data  and 
provides  it  to  the  task  controUer.  For  tools,  the  device  controUer  converts  task  controUer 
tool  commands  to  the  low  level  device  ampUfier  signals  and  returns  to  the  task  controUer  the 
tool  status. 

INPUT:  Device  commands  from  the  task  controUer  and  status  from  the  device  ampUfier 

OUTPUT:  Device  ampUfier  signals  to  the  the  device  ampUfier  and  status  to  the  task  con- 
troUer 


HC  4 - Device  Amplifier: 

RESPONSIBILITY:  The  device  ampUfier  provides  the  analog  or  digital  control  signal  to 
the  device.  This  could  be  analog  voltage  or  a PWM  signal  to  a motor  drive  or  power  to  a 
sensor.  A device  ampUfier  iriodule  also  generates  the  raw  feedback  data  from  the  device. 

INPUT:  Device  ampUfier  commands  from  the  device  controUer  and  status  from  the  device 

OUTPUT:  Control  signals  to  the  device  and  status  to  the  device  controUer 


HC  5 - Device: 

RESPONSIBILITY:  The  device  is  the  hardware  that  is  being  controUed  or  the  sensor 
that  is  being  used 

INPUT:  Control  signals  from  the  device  ampUfier 
OUTPUT:  Device  action,  e.g.,  motion  or  sensing 
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B.3  Software  Components 

The  types  of  software  modules  in  the  system  were  described.  Software  modules  in  the  system 
will  now  be  described  as  software  components  with  specified  responsibilities,  inputs  and  outputs. 
Some  of  the  components  could  be  further  decomposed  into  multiple  software  modules.  The 
application  programs  are  treated  here  as  software  components  and  are  given  below. 

B.3.1  System  Software  Components 
SC  1 - Object  Modeling: 

RESPONSIBILITY:  Provide  functionality  for  modebng  objects.  This  includes  initial  off- 
line description  of  objects  and  run-time  model  building. 

INPUT:  Object  types,  kinematics,  attributes,  operator  input 

OUTPUT:  Updated  object  types,  kinematics,  attributes 


SC  2 — Object  Calibration: 

RESPONSIBILITY:  Calibration  of  an  object’s  actual  properties,  e.g.,  position 
INPUT:  Object  initial  calibration  properties,  data  on  actual  properties 
OUTPUT:  Updated  object  calibration  properties 

SC  3 - Trajectory  Description: 

RESPONSIBILITY:  Generate  a trajectory  for  use  in  an  appbcation  program 

INPUT:  Path  information  such  as  starting  and  end  points,  continuous  inputs  such  as  from 
a hand  controller,  preferred  path  segments 

OUTPUT:  Trajectory  for  insertion  into  task  program 

SC  4 - Object  Knowledgebase: 

RESPONSIBILITY:  Store  information  about  objects  in  the  task  environment  including 
geometry,  task  information  and  functions  to  call  to  acquire  data 

INPUT:  Object  information 
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OUTPUT:  Object  information 


SC  5 - Operator  Input  Device  Control: 

RESPONSIBILITY:  Transform  operator  input  information  into  data  for  software  mod- 
ules and  provide  feedback  through  input  devices,  e.g.,  force  reflection 

INPUT:  Operator  inputs,  e.g.,  keyboard,  audio  and  handcontroller  and  feedback  data 

OUTPUT:  Data  to  system  modules  and  feedback  to  operator  through  input  devices 


SC  6 - Status  Graphical  Display: 

RESPONSIBILITY:  Display  system  status  including  geometry,  sensor  data,  and  task 
execution 

INPUT:  Object  status,  task  execution  status,  system  status 
OUTPUT:  Status  and  geometry  displays  to  operator 


SC  7 - Task  Program  Editor: 

RESPONSIBILITY:  Provide  an  interactive  interface  to  program  developer  for  task  se- 
quence (application  program)  generation  and  modification 

INPUT:  Information  to  generate  application  programs,  e.g.,  task  commands,  macros,  task 
sequences,  object  information,  trajectories,  rules 

OUTPUT:  Application  program  including  task  programs 

SC  8 - Task  Program  Supervisor: 

RESPONSIBILITY : Provide  operator  based  sequence  execution  control.  Allows  for  single 
stepping  commands,  sending  complete  sequences  and  backing  up.  AUows  task  program  editor 
to  modify  sequence. 

INPUT:  Application  task  programs,  status,  and  operator  inputs 
OUTPUT:  Task  program  commands  or  sequences  to  task  program  sequencers 
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SC  9 - Analysis  & Diagnosis: 

RESPONSIBILITY:  Analyze  and  diagnose  task  execution  status  such  as  checking  for 
collisions 

INPUT:  Task  execution  status  and  task  information  on  what  and  how  to  monitor 
OUTPUT:  Execution  status  and  execution  control  commands  such  as  stop 

SC  10  — Subsystem  Simulation: 

RESPONSIBILITY:  Provide  a simulation  of  the  task  execution  with  same  inputs  and 
outputs  as  the  the  real  system 

INPUT:  Task  program  commands 

OUTPUT:  Simulated  task  level  control  system  data 

SC  11  - Task  Knowledgebase: 

RESPONSIBILITY:  Provide  task  sequence  building  blocks  such  as  macro  commands  and 
sequences 

INPUT:  Requests  for  commands  or  command  types 

OUTPUT:  Macro  commands  and  sequences  with  unbound  parameters 

SC  12  - Subsystem  Task  Program  Sequencing: 

RESPONSIBILITY:  Sequence  the  subsystem  task  program  commands 

INPUT:  Task  programs  and  execution  status 

OUTPUT:  Task  level  control  commands  and  execution  status 

SC  13  - Parent  Task  Program  Sequencing: 

RESPONSIBILITY:  Sequence  the  parent  task  program  commands 
INPUT:  Parent  task  program  and  execution  status 

OUTPUT:  Coordination  commands  to  the  subsystem  task  program  sequencers 
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SC  14  - Subsystem  Task  Level  Coordinated  Control: 

RESPONSIBILITY:  Execute  non-closed  loop  control  of  task  programs 

INPUT:  Task  program  commands  and  data  from  sensors,  tools  and  mechanisms 

OUTPUT:  Commands  to  task  level  closed  loop  control,  sensors,  tools  and  mechanisms  and 
status 

SC  15  - Subsystem  Task  Level  Closed  Loop  Control: 

RESPONSIBILITY:  Execute  closed  loop  control  of  task  programs 

INPUT:  Commands  to  closed  loop  control  modules  and  data  from  sensors,  tools  and  mech- 
anisms 

OUTPUT:  Commands  to  sensors,  tools  and  mechanisms  and  status 


SC  16  — Task  Control  Database: 

RESPONSIBILITY:  Store  and  provide  information  relevant  to  the  task  execution  system 
such  as  status  to  be  sent  periodically  to  the  object  knowledgebase  and  actual  data  to  be  used 
which  is  associated  with  symbolic  parameters 

INPUT:  Status  data  and  database  commands 

OUTPUT:  Status  data 

SC  17  — Sensor  Control: 

RESPONSIBILITY:  Provide  control  of  a sensor 

INPUT:  Sensor  commands  and  raw  sensor  data 

OUTPUT:  Processed  sensor  data  and  low  level  sensor  commands 


SC  18  - Tool  Control: 

RESPONSIBILITY:  Control  a tool 
INPUT:  Tool  control  commands  and  tool  status 
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OUTPUT:  Low  level  tool  commands  such  as  analog  voltage  and  tool  status 


SC  19  - Robot  Servo  Control: 

RESPONSIBILITY:  Provide  joint  level  servo  control 

INPUT:  Robot  configuration  commands  and  status 

OUTPUT:  Low  level  robot  joint  commands  such  as  voltage  and  status 


SC  20  - Virtual  Sensor: 

RESPONSIBILITY:  Compute  information  as  if  it  came  from  a real  sensor,  but  using 
available  data,  such  as  for  multiple  sensor  fusion 

INPUT:  Sensor  commands  and  data 

OUTPUT:  Computed  virtual  sensor  data 


SC  21  - Motion  Fusion: 

RESPONSIBILITY:  Combine  the  various  sources  of  motion  into  a task  level  motion 
command  for  the  mechanism 

INPUT:  Motion  commands  from  the  various  motion  control  components,  e.g.,  force  control, 
visual  servoing,  trajectory  generator,  teleop  motion;  parameters  specifying  weights  for  each 
axis  of  control  for  each  motion  source 

OUTPUT:  A combined  task  level  motion  command  for  the  mechanism.  This  is  taken  by 
the  task-device  map  component  and  transformed  into  commands  to  the  mechanism  servoed 
axes. 


SC  22  - Teleop  Motion: 

RESPONSIBILITY:  Read  hand  controller  inputs  and  generate  motion  commands  for 
hand  controller 

INPUT:  Hand  controller  motion  input  data  from  hand  controller  device  control 
OUTPUT:  Motion  command  associated  with  teleoperation 
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SC  23  - Force  Control: 

RESPONSIBILITY:  Perform  closed  loop  force  control  and  generate  motion  commands 
for  force  control 

INPUT:  Sensed  force  data,  force  setpoints,  force  control  parameters 
OUTPUT:  Motion  command  associated  with  force  control 

SC  24  - Task  Space  Trajectory  Generator: 

RESPONSIBILITY:  Generate  task  space  pose  trajectory  and  provide  associated  motion 
commands  from  trajectory  generator 

INPUT:  Trajectory  parameters,  goal  position,  obstacle  information 

OUTPUT:  Trajectory  setpoints  representing  motion  inputs  from  trajectory  generator 


SC  25  - Proximity  Servo: 

RESPONSIBILITY:  Perform  closed  loop  proximity  control  and  generate  motion  com- 
mands for  proximity  control 

INPUT:  Sensed  proximity  data,  proximity  setpoints,  proximity  control  parameters 
OUTPUT:  Motion  command  associated  with  proximity  control 


SC  26  - Orientation  Servo: 

RESPONSIBILITY:  Perform  closed  loop  orientation  control  and  generate  motion  com- 
mands for  orientation  control 

INPUT:  Sensed  orientation  data,  orientation  setpoints,  orientation  control  parameters 
OUTPUT:  Motion  command  associated  with  orientation  control 

B.3.1.1  Application  Program  Components 
SC  27  - Mobile-Platform-Control: 

RESPONSIBILITY:  This  program  is  for  positioning  the  mobile  platform  in  an  appro- 
priate location  relative  to  the  surface  targeted  for  paint  stripping.  The  mobile  platform 
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can  be  placed  to  the  desired  location  and  posture  automatically  by  the  system  using  the 
preassigned  data  or  manually  by  the  operator  using  the  hand  controller.  The  selection  of 
automatic  control  mode  in  turn  provides  options  for  designating  the  platform  location  and 
posture.  Manual  control  can  share  control  with  automatic  control,  as  desired.  The  platform 
is  fixed  upon  the  completion  of  the  task.  A more  advanced  future  system  may  have  coor- 
dinated platform  and  manipulator  control,  but  this  would  require  accurate  platform  control 
and  real-time  platform-manipulator  combination  position  information  relative  to  the  aircraft 
which  wiU  probably  not  be  available  in  the  first  implementation. 

INPUT:  - PAR  AMETERS  LIST  - 

— The  final  desired  pose  of  the  mobile  platform  in  case  of  the  automatic  control  mode 
— The  desired  platform  pose  increment  in  case  of  the  manual  control  mode 
OUTPUT:  - PARAMETERS  LIST  - 

- The  system  state  including  current  pose  of  the  mobile  platform 
— The  execution  state,  e.g.,  completion  state  for  automatic  control 


SC  28  - Worksite- Registration: 

RESPONSIBILITY:  This  program  is  for  configuring  the  manipulator  in  an  appropriate 
position  of  the  worksite  to  start  the  desired  tool  (gun)  motion.  The  position  of  the  manipu- 
lator base  relative  to  the  aircraft  skin  area  to  be  stripped  is  determined.  The  data  required 
for  the  worksite  registration  should  be  provided  as  input,  which  include  the  distance  of  tool 
separation,  the  orientation  of  tool  with  respect  to  the  surface,  and  the  landmarks  or  features 
of  targeted  surface  (such  as  the  surface  curvature  that  can  be  measured  by  the  force/torque 
or  tactile  sensor).  The  manual  mode  of  control  combined  with  the  sensor-based  distance  and 
orientation  servos  can  accomplish  this  task.  This  program  and  the  mobile-platform-control 
can  be  used  together  for  two  consecutive  paint-stripping  operations. 

INPUT:  - PARAMETERS  LIST  - 

- The  data  for  worksite  registration,  including  the  stand-off  distance  and  the  orienta- 
tion of  the  tool  with  respect  to  the  targeted  surface 

- The  priority  setting  between  manual  and  sensor-based  automatic  operation 

OUTPUT:  - PARAMETERS  LIST  - 

— The  measured  data  from  the  sensors 
— The  current  manipulator  pose 
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SC  29  - Paint-Stripping-Operation: 

RESPONSIBILITY:  This  program  is  for  stripping  paint  off  the  skin  of  a large  aircraft 
based  on  supervisory  and  shared  telerobotics  control.  Prior  to  running  this  program,  the 
following  initialization  is  required: 

— Setting  up  the  mobile  platform  to  an  appropriate  position. 

- Configuring  the  manipulator  at  the  initial  pose  for  worksite  registration. 

Upon  execution  of  this  program  the  operator  is  asked  whether  the  initial  set-up  by  mov- 
ing the  mobile  platform  to  the  desired  location  and  configuring  the  manipulator  at  the 
start  position  are  done.  If  not,  the  operator  should  open  the  mobile- platform- control  and 
worksite-registration  programs  by  clicking  the  corresponding  icons  and  execute  them  for  the 
initialization.  Once  the  initial  set-up  is  completed,  the  operator  is  asked  to  assign  the  system 
parameters  and  control  modes. 

INPUT:  - PARAMETERS  LIST  - 

— Off  line  generated  tool  path 

— Run  time  generated  tool  path 

— The  desired  separation/stand-off  of  the  tool  from  the  target  surface 
— The  desired  tool  orientation  relative  to  the  target  surface 

— The  constraints  on  tool  path  such  as  the  constrained  motion  imposed  on  individual 
axes 

— Tool  speed 

- PMB  (Plastic  Media  Bead)  pressure 

— The  selection  of  the  motion  input  sources  affecting  the  tool  (which  will  indicate  the 
desired  control  mode) 

OUTPUT:  - PARAMETERS  LIST  - 

— Commands  to  the  task  control  including  equivalent  commands  associated  with  the 
application  command  inputs  above 

— Status  of  execution  including  manipulator  status,  sensors’  status,  and  current  sub- 
task status  for  use  in  analysis  and  display  to  the  operator 
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Annex  C 

(normative) 

Environment  Profile  Suite 


Annex  C contains  a list  of  the  profiles  that  can  be  used  to  generate  a UTAP  system  specification. 
Each  module  in  the  system  would  be  required  to  fill  out  one,  maybe  several,  generic,  error  and 
data  knowledge  profiles  - depending  on  the  number  of  upper  and  subsystem  links  in  the  system. 
For  now,  only  the  local  modules  have  been  specified. 

C.l  Application  Environment  Profile 

A UTAP  module  shall  conform  to  the  environment  which  includes  system  profile  that  names 
each  hardware  device  and  device  profile  in  the  system.  A device  could  be  a computer  or  control 
device.  The  system  profile  runs  under  a system  environment  which  is  also  profiled.  This  system 
environment  profile 

Computer  boards  have  a device  profile  that  includes  CPU  type,  CPU  characteristics  and  the 
CPU  performance  characteristics.  Included  profile  is  the  operating  system  support  for  the  CPU. 

Controller  boards  are  devices  that  would  have  a application-specific  profile. 

The  system  environment  describes  the  infrastructure  support  (such  as  communication  mecha- 
nisms) and  resources  (disks,  extra  memory,  etc.)  available  to  system  devices. 


Table  C.l  — System  Profile 


DEVICE 

Device  Profile 

Platform 

Table  C.2  - System  Environment  Profile 

Bus:  

Memory:  

Disk:  

Disk  Memory:  

Floppy  Disk:  

Floppy  Size:  

Floppy  Density:  

Compact  Disk  : 

LAN  Cabling:  

LAN  Protocol:  
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Table  C.3  - Processor  Board  Profile 

Board  Id  

CPU  Type  

Memory:  

OS  Type:  

OS  Version:  

OS  Release:  

BUS  Support  

lO  Support  

Peripheral  Support  

Special:  


C.2  Interface  Environment  Profile 

A universal  format  is  assumed  in  developing  the  message  interfaces.  It  is  assumed  that  each 
module  displays  a similar  flow  of  messages.  Figure  C.l  iUustrates  the  message  flow  of  a module.  A 
message  naming  convention  is  used  for  improved  comprehension.  Within  a messages,  a keyword 
is  used  to  delineate  between  mode/goal/state  information.  The  keywords  are  grouped  by  type: 

- MESSAGING  (i.e.,  BLOCK,  MACRO,  PLAN,  EVENT,  SELECTION) 

- SEQUENCING  CONTROL:  generics  (i.e.,  STARTUP,  SHUTDOWN,  ENABLE,  DIS- 
ABLE, etc.) 

- MODALITY:  USE,  START,  STOP,  COMPUTE 

- PARAMETRIC:  LOAD,  INCREMENT,  SELECT 

- DATA  COMMAND:  SET,  ADJUST,  GET 

- STATUS:  POST 
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POST 

(usa  DATAKNOKWLEOGE  Profile) 


MODE  PARAMETER  - USE,  START,  STOP 
CONTROLPARAMETER:  - LOAD,  INCREMENT, 

DATA  RIVRAMETER:-  SET,  ADJUST,  JOG, 

REQUEST  DATA  - use  DATA  KNOWLEDGE  Profile  (GET) 
GENERIC  PRORLE 
STARTUP,  SHUTDOWN,  RESET 
ENABLE(ld),  DISABLE(id),  ESTOP 
INR,START,STOPJVBORi; 

SUSPEND,RESUME, 

{BEOIN,NEXT,CLEAR)_SINGLE_STEP, 

MARK_BREAKPOINT,MARK_EVENT 


il 


STATUS 

or 

DATA  READINGS 


GOALCOMMAND 

or 

OBJECT  KNOWLEDGE  REQUEST 


jiauejq 

CONRG: 

• upper  system  (link) 

- functions 

(IMtpsystema  used  (list) 

- parameters  needed  for 
Mnptibdata  (for 
imttpa)  data  (from 
irlotfoli  Request  data 

- output  request 
•Ivadata 


STATUS 
RECEIVE  DATA 


ATT 


COMMAfO 
REQUEST  DATA 


[STATUS 
RECEIVE  DATA 


COMMAND 
REQUEST  DATA 


POST  (usa  DATA  KNOWLEDGE  Profile) 
mrr 

MODE  PARAMETER  - USE,  START  STOP 
CONTROLPARAMETER  • LOAD,  INCREMENT, 
DATA  PARAMETER  - SET,  ADJUST,  JOG, 
REQUEST  DATA  - use  DATA  KNOWLEDGE  Profile  (GET) 
GENERIC  PRORLE 
STARTUP,  SHUTDOWN,  RESET 
ENABLE(ld),  DiSABLE(id),  ESTOP 
INrTSTART,STOPJtBORT, 
SUSPEND,RESUME, 
{BEGIN,NEXT,CLEAR}_SINGLE_STEP, 
MARK_BREAKPOINT,MARK_EVENT 


n-1 


JM 

POST  (usa  D/SA  KNOWLEDGE  Profile) 
nirr 

MODE  PARAMETER  • USE,  START,  STOP 
CONTROLPARAMETER  - LOAD,  INCREMENT, 

DATA  PARAMETER-  SET,  ADJUST,  JOG, 

REQUEST  DATA  - use  DATAKNOWLEDGE  Profile  (GET) 
GENERIC  PRORLE 
STARTUP)  SHUTDOWN,  RESET 
ENABLE(ld),  OISABLE(id),  ESTOP 
INrT,START,STOPJtBORT 
SUSPEND,RESUME, 
{BEGIN,NEXT,CLEAR}_SINGL£_STEP, 
MARK_BREAKPOINT,MARK_EVENT 


Figure  C.l  - Module  Profile 


Specification 
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Table  C.4  - Generic  Message  Profile 


Configuration 

N^l^le  

Module  Type  


MESSAGE  PRIMITIVES  Comply 

BLOCK  

MACRO  

PLAN  

EVENT  

USE^ELECTION  


SEQUENCE  Comply 

Powerup  STARTUP  

SHUTDOWN  

RESET  

S/E  ENABLE  

DISABLE  

ESTOP  

Software  START  

STOP  

HALT  

HOLD  

SUSPEND  

RESUME  

BEGIN^INGLE^TEP  

NEXT_SINGLE^TEP  

CLEAR^INGLE^TEP  

MARK-BREAKPOINT  

MARK.EVENT  

Status  LOAD-STATUS.TYPE  

LOAD-STATUS-PERIOD  

STATUS-REPORT  


OBJECT  DATA  Comply 

POSTJD  

GET-OBJECT-ID  

USE-OBJECT  

GET-FEATURE  

USE-FEATURE  

GET.VALUE  

POST-VALUE  

GET.LIST  

POST-LIST  
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Table  C.5  - Data  Knowledge 

Configuration 

Name  

Module  Type  


ATTRIBUTES  Actual  Desired  Max  Min  Avg  History 

POSTJIESPONSE  

GET-SELECTION  

GET.TIME  

GET-POSITION  

GET.ORIENTATION  

GET.POSE  

GET.VELOCITY  

GET-ACCELERATION  

GET-IERK  

GET.FORCE  

GET-TORQUE  

GET-MASS  

GET-TEMPERATURE  

GET-PRESSURE  

GET-VISCOSITY  

GET-LUMINANCE  

GET-HUMIDITY  

GET-GEOMETRY  

GET-TOPOLOGY  

GET-SHAPE  

GET-PATTERN  

GET-MATERIAL  

GET-KINEMATICS  


Table  C.6  — Errors 

Configuration 

Name  

Module  Type  


ERRORS  Comply 

POSIX  ERRORS  

CMD-NOTJMPLEMENTED  

ERROR-COMMAND-ENTRY  

ERROR-DUPLICATE-NAME  

ERROR-BAD-DATA  

ERROR-NO-DATA-AVAIL  

SAFETY-VIOLATION  

LIMIT-EXCEEDED  

ERROR-OVER-SPECIFIED  

ERROR-UNDER.SPECIFIED  
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Table 

Name 
Module  Type 
Links-Up: 
Links  JDown: 
Other: 

Interface: 

Safety: 

Units: 

Reference: 

Representation: 

Compensation: 


Gains: 

Limits: 


C.7  - Axis  Servo  Command  Profile 


Configuration Comply 


USJVXIS^ERVO 

TASKXEVEL.CONTROL 

PIO 


GENERICS 

DATA  KNOWLEDGE 

ERRORS 


MODES 

SET-BRAKES 

CLEAR.BRAKES 


MODES 

INPUT 

USE-ANGLES 
USE-RADIANS 
USEJ^BSOLUTE 
USE-RELATIVE 
USE-POSITION 
USE-VELOCITY 
USE-CURRENT 
USE-VOLTAGE 
USE-FEEDFORWARD-TORQUE  

SELECTIONS  Comply 

USE-PID  

USE-STIFFNESS  

USEJMPEDANCE  

USE-COMPLIANCE  


AUGMENTATIONS 

{START— STOP}-GRAVITY-COMP 

PARAMETER  LOADS  Comply 

LOAD-DOF  

LOAD-CYCLE-TIME  

LOAD-AXIS-MASK  

LOAD-STATUS-UPDATE  

LOAD-SAMPLING-PERIOD  

LOAD-FREQUENCY-RESPONSE  

LOAD-PID  

LOAD-DAMPING-VALUES  

LOAD-JOINT-LIMIT  

LOAD-VELOCITY-LIMIT  

LOAD-GAIN-LIMIT  


Comply 


Comply 
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Table  C.8  — Axis  Servo  Data  Profile 


Configuration 

Input  Command  Data  SET  ADJ 

POSITION  

VELOCITY  

TORQUE  

VELOCITY  

ACCELERATION  

FORCES  


Request  Input/ 

Output  Posted  SET  ADJ 

Position:  ACTUAL  

DESIRED  

MAX  

MIN  

HISTORY(-t,tO)  

Velocity:  ACTUAL  

DESIRED  

MAX  

MIN  

HISTORY(-t,tO)  


Output  Status 
See  - Data  Knowledge 

SUBSYSTEM  LINK 
Name:  


Command  Data 

See  - Subsystem  Module  Profile 


Request  Data 
See  - Data  Knowledge 


Receive  Data 

See  - Data  Knowledge 


JOG 


JOG 
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Table  C. 


Name 
Module  Type 
Class: 
Links.Up: 
Links  JDown: 
Other: 

Interface: 


Name: 


— Tool  Control  Profile  - 

Configuration 


US.TOOL. 

“Spindle” 

TASK_LEVEL.CONTROL 

PIO 


GENERICS 

DATA  KNOWLEDGE 

ERRORS 

MODES 
SELECTIONS 
START  TURNING 
STOP  TURNING 
LOCK-Z 
UNLOCK.Z 

AUGMENTATIONS 

USEJORCE 

USEJMO-FORCE 

PARAMETER  LOADS 

LOAD.SPEED 

SPINDLE.ORIENT 


Input  Data  Accepted 
SPINDLE-RETRACT.TRAVERSE 
SPINDLEJRETRACT 
SPINDLE-ORIENT 


Output  Status 
See  - Data  Knowledge 

SUBSYSTEM  LINK 


Command  Data 

See  - Subsystem  Module  Profile 


Request  Data 
See  - Data  Knowledge 


Receive  Data 

See  - Data  Knowledge 


Spindle 

Comply 


Comply 


Comply 


Comply 
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Table  C.IO  — Tool  Control  Profile  - Coolant 


Configuration 

Name  

Module  Type  US_TOOL_ 

Class;  “Spindle” 

Links.Up:  TASK-LEVEL-CONTROL 
Links-Down:  PIO 

Other:  


Comply 


Interface;  GENERICS 

DATA  KNOWLEDGE 
ERRORS 


MODES  Comply 

SELECTIONS 

START  MIST  

STOP-MIST  

START-FLOOD  

STOP-FLOOD  


Input  Data  Accepted 
See  - Data  Knowledge 

Output  Status 
See  - Data  Knowledge 

SUBSYSTEM  LINK 

Name;  


Command  Data 

See  - Subsystem  Module  Profile 


Request  Data 
See  - Data  Knowledge 


Receive  Data 

See  - Data  Knowledge 
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Table  C.ll  — Generic  Sensor 


Configuration 

Name  

Module  Type  US-SENSOR- 
Class:  “Generic” 

Links-Up:  TASK.LEVEL.CONTROL 
LinksJDown:  PIO 

Other:  


Interface:  GENERICS 

DATA  KNOWLEDGE 
ERRORS 


MODES 

use:  USEJdEASUREMENT.UNITS 


SELECTIONS 

START/STOP  US-START-TRANSFORM 
US-STOP-TRANSFORM 
US-START-FILTER 
US^TOP-FILTER 

PARAMETER 

load:  US_LOAD_SAMPLING^PEED 
USXOAD-FREQUENCY 
US-LOAD.TRANSFORM 
US_LOAD_FILTER 

Input  Data  Accepted 
set:  POSITION 

ORIENTATION 

Output  Status  Posted 
See  Data  Knowledge 
post:  SENSORJOST-READING 

SCALAR-SENSORJ^OST-READING 
VECTOR-SENSOR-POST  JlEADING 

Output  Status 
See  - Data  Knowledge 

SUBSYSTEM  LINK 

Name:  


Command  Data 

See  - Subsystem  Module  Profile 


Request  Data 
See  - Data  Knowledge 


Receive  Data 
See  - Data  Knowledge 
get:  GET-READING 

G ETJVTTRIBUTES  -RE  ADING 


Comply 


Comply 


Comply 
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Table  C.12  - Sensor  - Image 


Configuration 

Name  

Module  Type  US-SENSOR. 

Ciass:  “Image” 

Links-Up:  TASK-LEVEL.CONTROL 
LinksJDown:  PIO 

Other:  


Interface:  GENERICS 

DATA  KNOWLEDGE 
ERRORS 

MODES 

use:  USJMAGE-USE-FRAME-GRABJVIODE 
USJMAGE-USE-HISTOGRAM-MODE 
USJMAGE.USE.CENTROID.MODE 
USJMAGE-USE.GRAYXEVEL-MODE 
USJMAGE-USE-THRESHOLD-MODE 
USJMAGE-COMPUTE.SPATIAL-DERIVATIVES_MODE 
USJMAGE.COMPUTE.TEMPORALJDERIVATIVESJVIODE 
USJMAGE.USE-SEGMENTATATION-MODE 
USJMAGE.USE-RECOGNITION-MODE 
USJMAGE.COMPUTE.RANGE-MODE 
USJMAGE-COMPUTE-FLOWJ^ODE 


PARAMETER 

load:  USJMAGEXOAD.CALIBRATION 


Input  Data  Accepted 
set:  POSITION 

ORIENTATION 

USJMAGE-ADJUST-POSITION 

USJMAGE-ADJUST-FOCUS 

Output  Status  Posted 
See  - Data  Knowledge 
post:  US-2D^ENSOR-POST-READING 
USJMAGE-POST-SPECIFICATION 
USJMAGE-POST-PIXEL-MAP-READING 
USJMAGEJ>OST-HISTOGRAM_READING 
USJMAGE-POST-XY.CHAR-READING 
USJMAGEJOST-BYTE-SYMBOLICJIEADING 
USJMAGEJOST-THRESHOLD-READING 
US-IMAGE-POST-SPATIAL-DERIVATIVE_READING 
US-IMAGEJOST-TEMPORAL-DERIVATIVE-READING 
USJMAGEJ^OSTJIECOGNITION.READING 
USJMAGE-POSTJIANGE-READING 
USJMAGEJOSTJLOWJIEADING 


Request  Data 

- See  Data  Knowledge 

get:  GET-READING 

GET-ATTRIBUTES.READING 


Receive  Data 

See  - Data  Knowledge 


Comply 


Comply 


Comply 
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Table  C.13  — Subsystem  Task  Level  Control 


Con'figuration 

Name  

Module  Type  US.TLC. 

Class:  “Generic” 

Links.Up:  TASK-PROGRAM^EQUENCER 

LinksJDown:  

Other:  


Interface:  GENERICS 

DATA  KNOWLEDGE 
ERRORS 

MODES 

use:  US.TLC.USE_JOINT.REFERENCE.FRAME 

US.TLC-USE.CARTESIAN.REFERENCEJRAME 
US.TLC.USEJIEPRESENTATION.UNITS 
US-TLC-USEJVBSOLUTE-POSITIONING.MODE 
US-TLC-USEJIELATIVEJ^OSITIONING-MODE 
US.TLC.USE.WRIST.COORDINATE.FRAME 
US-TLC.USE.TOOL.TIP.COORDINATE.FRAME 
US.TLC.USEJVIODIFIED.TOOL-LENGTH.OFFSETS 
US-TLC.USE-NORMAL.TOOL-LENGTH.OFFSETS 
US-TLC.USE-NO-TOOL-LENGTH.OFFSETS 
US.TLC.USEJ<INEMATIC.RINGJ»0SITI0NINGJV10DE 
load:  US.TLCXOAD-DOF 

US-TLC-LOAD.CYCLE.TIME 

US-TLC-LOADJIEPRESENTATION.UNITS 

US.TLCXOAD-LENGTH-UNITS 

US-TLC.LOADJRELATIVE.POSITIONING 

US.TLC.ZERO_RELATIVE_POSITIONING 

US.TLC-ZERO_PROGRAM.ORIGIN 

US-TLC-LOAD-KINEMATIC-RING_POSITIONINGJVIODE 

US.TLC.LOAD-BASEJ^ARAMETERS 

US.TLC-LOAD-TOOL-PARAMETERS 

US.TLC-LOAD.OBJECT 

US.TLC-LOAD-OBJECT-BASE 

US.TLCXOAD.OBJECT.OFFSET 

US.TLCXOADJDELTA 

US-TLC-LOAD-OBSTACLE-VOLUME 

US-TLC-LOAD_NEIGHBORHOOD 

US-TLC-LOADJEED-RATE 

US.TLC-LOAD.TRAVERSE-RATE 

US.TLCXOADJVCCELERATION 

US.TLCXOAD_JERK 

US.TLC.LOADJROXIMITY 

US-TLC-LOAD-CONTACT-FORCES 

US-TLC-LOAD-JOINT-LIMIT 

US-TLC-LOAD.CONTACT.FORCE-LIMIT 

US-TLC.LOAD.CONTACT.TORQUE.LIMIT 

US-TLC.LOAD-SENSOR-FUSION-POS-LIMIT 

US-TLCXOAD^ENSORJUSION.ORIENT-LIMIT 

US.TLC-LOAD_SEGMENT.TIME 

US.TLC-LOAD.TERMINATION.CONDITION 

US-TLC-INCR-VELOCITY 

US-TLCJNCR^CCELERATION 


Comply 


Comply 
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Table  C.14  — Subsystem  Task  Level  Control  - cont. 

selections:  US.TLC.START.MANUALJVIOTION  

US.TLC.STOPJV1ANUAL.MOTION  

US.TLC-START-AUTOMATIC.MOTION  

US-TLC-STOPJ^UTOMATIC.MOTION  

US-TLC.START-TRAVERSE_MOTION  

US.TLC.STOP.TRAVERSE.MOTION  

US-TLC-START.GUARDED-MOTION  

US-TLC-STOP.GUARDEDJVIOTION  

US-TLC-START.COMPLIANT.MOTION  

US.TLC-STOP.COMPLIANT.MOTION  

US-TLC.START-FINE-MOTION  

US-TLC^TOP-FINE-MOTION  

US.TLC-START-MOVE-UNTIL-MOTION  

US-TLC-STOPJVIOVE.UNTIL-MOTION  

US.TLC-START-STANDOFF-DISTANCE  

US-TLC^TOP-STANDOFFJ3ISTANCE  

US-TLC-START-FORCEJOSITIONING-MODE  

US_TLC.STOPJORCE-POSITIONING-MODE  


Input  Data  Accepted 
US-TLC-SET.GOALJOSITION 
US.TLC-GOAL-SEGMENT 
US.TLC-ADJUST-AXIS 


Output  Status 
See  - Data  Knowledge 

SUBSYSTEM  LINK 

Name:  


Command  Data 

See  — Subsystem  Module  Profile 


Request  Data 
See  - Data  PCnowledge 


Receive  Data 

See  - Data  Knowledge 

US-TLC-UPDATE-SENSORJUSION 
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Table  C.15  - Subsystem  Task  Level  Control 


Configuration 

Name  

Module  Type  US-TLC_ 

Cl^lss:  “Generic” 

Links.Up:  TASK.PROGRAM-SEQUENCER 

LinksJDown;  

Other:  


Comply 


Interface:  GENERICS 

DATA  KNOWLEDGE 
ERRORS 


MODES  Comply 

Task  Level  Generics  

use:  US.TLC_SELECT.PLANE  

US.TLC.USE.CUTTER.RADIUS.COMPENSATION  

load:  US.TLCX0ADJ30F  

selections:  US.TLC^TART.CUTTER.RADIUS.COMPENSATION  

US.TLC-STOP-CUTTER-RADIUS.COMPENSATION  


Input  Data  Accepted 

US.TLC-STRAIGHT.TRAVERSE 

US.TLC-ARC.FEED 

US-TLC^TRAIGHT-FEED 

US-TLC-PARAMETRIC-2D-CURVE-FEED 

US.TLC-PARAMETRIC.3D.CURVE.FEED 

US.TLCJ^URBS-KNOT.VECTOR 

US-TLCJMURBS.CONTROL.POINT 

US-TLC-NURBS-FEED 


Output  Status 
See  - Data  Knowledge 

SUBSYSTEM  LINK 

N^lme:  


Command  Data 

See  - Subsystem  Module  Profile 


Request  Data 
See  - Data  Knowledge 


Receive  Data 

See  - Data  Knowledge 

US.TLC-UPDATE-SENSORJUSION 
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Annex  D 

(informative) 

Examples 


D.l  API  Interface  Example 

The  UTAP  message  format  provides  the  size  and  structure  for  the  interfaces.  The  UTAP  mes- 
sages define  the  information  that  crosses  the  communication  channel  (or  link  or  wire).  This 
message  interface  is  supposed  to  be  flexible,  but  not  necessarily  suitable  for  application  pro- 
gramming. One  may  require  an  API  to  sit  between  the  message  interface  and  the  programmer, 
much  like  a device  driver  hides  the  implementation  details  of  a device.  Figure  D.l  illustrates 
the  relationship  between  the  superior  and  the  subordinate  in  such  a setup.  An  API  exists  in  the 
superior  as  a abstraction  mechanism  for  communicating  with  the  subordinate. 

The  programmer  can  use  the  UTAP  isomorphic  functional  API  or  can  use  existing  software  that 
has  a customized  middleware  to  map  the  application  code  into  the  UTAP  message  interface.  This 
section  will  present  an  example  that  illustrates  the  first  possibility  - using  the  UTAP  isomorphic 
functional  API  for  servo  control.  The  hope  is  that  this  functional  API  is  similar  to  most  existing 
products  and  can  be  achieved  by  renaming  keywords  with  new  procedural  names  and  reordering 
the  procedural  parameters. 

An  example  to  control  a IDOF  servo  from  the  task  level  control  module  will  be  developed.  In 
this  example,  the  first  point  of  illustration  wiU  be  to  use  the  API  to  define  a hi-gain  and  a 
low-gain  mode.  Within  the  example,  the  API  subroutine  calls  still  use  the  heap  (or  pointer  to 
the  data)  concept  to  pass  parameters. 

hi_gain(){ 

double  p=100,  i=200,  d=20: 
double  iliniit=30; 

us_begin_macro("hi_gain") ; 
us_axis_servo_load_pid_gain(ftp,ti ,td) ; 

limiti=250;  us_axis_8ervo_load_integration_limit(ftilimit) ; 
us_end_macro() ; 

} 

lo_gain(){ 

double  p=50,  i=200,  d=20; 
double  ilimit=30; 

us_begin_macro("lo_gaiii")  ; 
us_axi8_servo_load_pid_gain(tp,fti ,ftd) ; 

ilimit=250;  us_€uci8_servo_load_integration_limit(ftilimit) ; 
us.end.macroO  ; 

Once  we  have  the  parameters  and  modes  defined,  we  can  then  work  on  the  process  model. 
Within  the  SERVO  interface  process,  you  would  need  to  startup,  run,  and  shutdown. 

Servo_Interface_init()  •( 

us_axis_servo_load_dof (1) ; //  assign  dof  for  heap  mgt . 

us_axis_servo_use_degree_units() ; //  prefer  degrees  to  radians 

us_servo_init() ; //  init  servos 

us_8ervo_enable() ; // 

hi.gainO;  //  set  up  hi  gain 

lo_gain();  //  set  up  lo  gain 

} 
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Figure  D.l  — Superior  use  of  API  Interface  to  Command  Subordinate 

The  actual  process  will  be  to  initialize  the  servo,  use  hi-gain  parameters  with  PID  control 
mode,  and  then  move  to  a desired  joint  position.  The  concept  of  getting  and  updating  readings 
of  the  actual  position  will  also  be  developed.  The  test  fuzzy  .equal  was  coined  to  provide  an 
approximately  equal  function. 

Servo.InterfaceO  { 

double  joint; 

U8_use_selection(us_get_selection("D0FSERV01“)) ; 
us_axis_8ervo_load_absolute_positioning() ; 
us.startupO ; 

Servo_intorface_init() ; 
u8_u8e_macro("hi_gain") ; 

U8_u8e_pid() ; 

us_ajcis_8ervo_home  ();  //  reaet  8ervo8 

us.startO;  //  nos  the  system  sill  move  home 

//  One  time  move 
joint  = 10; 

us_axis_servo_8et_po8ition( joint) ; 

//  Post  actual  readings 
{ ROUTE  p; 

double  noB; 

p.type  = ROUTE . STATUS ; 

do  { noH=us_axi8_8orvo_get_position(p  , Modifier.t ..real) ; 

Bhile( ifuzzy.equalCnoB , joint) ) ; 

} 

} 

us_ajcis_8ervo_disable()  ; 
u8_axis_servo_shutdoBn() ; 

} 

This  example  illustrated  a simple  servo  interface.  Although  illustrative  it  presented  an  ad 
hoc  solution.  One  would  prefer  to  use  a more  elegant  internal  control  architecture  (e.g.,  see 
[RCS],  [ONIKA],  [CISC],  [STELER],  [TCA],  among  others  cited  in  Bibliography)  so  that  one  has 
better  coordination  of  the  sensing,  world  modeling  and  behavior  generation  aspects  of  intelligent 
control. 


D.1.1  Tool  Manipulation 

One  can  program  the  tool  in  several  methods.  A superior  module  can  enable  the  tool  in  the 
kinematic  ring  bitmask,  and  then  send  the  tool  transform.  Another  option  is  for  the  interface  to 
use  CHANGE-TOOL  and  TOOL-OFFSET  messages  and  override  the  kinematic  ring  selection 
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mask. 

The  tool  offset  messages  are  more  in  line  with  traditional  NC  tool  programming 
(see  [KRAMER]).  Within  the  UTAP  interface,  it  will  be  assumed  that  there  is  a table  of  40  tool 
length  offset  numbers,  and  one  or  more  registers,  each  with  a tool  length  offset  modifier  number. 
There  is  a tool  length  offset  mode  which  can  be  set  to  one  of  three  values:  NONE,  NORMAL, 
and  MODIFIED.  In  the  NONE  mode,  no  tool  length  offsets  are  used.  In  the  NORMAL  mode, 
the  tool  length  offset  value  in  the  position  of  the  table  with  the  same  index  as  the  tool  currently 
in  the  spindle  is  used.  In  the  MODIFIED  mode,  the  value  used  for  the  tool  length  offset  is  the 
modifier  number  in  the  currently  selected  modifier  register  added  to  the  offset  value  for  the  tool 
currently  in  the  spindle.  There  are  currently  no  commands  for  setting  the  values  in  the  tool 
length  offset  table  or  for  setting  the  values  of  the  modifier  numbers  in  the  modifier  registers. 


D.1.2  Sensor  Programming  Example 

The  sensor  messages  were  categorized  by  dimensionality.  The  sensors  were  genericaUy  grouped 
as  scalar,  vector,  and  2D  array.  Across  each  category,  the  GET_READINGS  message  is  generally 
universal.  On  the  other  hand,  posting  messages  were  customized  according  to  expected  sensors 
readings.  For  example,  although  one  can  construct  a force/torque  query  message  from  generic 
building  blocks,  it  is  redundant  since  this  sensor  is  so  common.  (For  example  one  can  use  the 
generic  message  GET_DATA_LIST  with  attribute  = -force  | -torque.)  Wherever  possible,  sensor 
readings  that  were  anticipated  to  be  common  were  given  a distinguishing  message  name. 

The  following  example  outlines  an  interface  to  a force  torque  sensor. 

ROUTE  route ; 

Attribute.t  attr; 

Nodifier_t  modifier; 
us_ft_sensor_po8t-reading-t  reading; 
double  fx,fy,fz; 
double  tx,ty,tz; 

//  setup  parameter  attribute  and  modifier  info 
attr  = Attribute-t .force  I Attribute.t .torque ; 
modif ier=Hodif ier.t . actual ; 

//  setup  routing  info 
route. type  = ROUTE . STATUS ; 
route. times  = 1 ; 

us_use_selection(us_get_selection("TLC:A;FORCE-TORQUE-SEISOR")) ; 
us-load-dof (3) ; 

us_load-sampling-speed(100Hz) ; // 

us-load_frequency( .10) ; // 

us_load-filter(us-sensor_load_filter_m8g-t .HI-PASS, 1000) ; 
us-Start-f  ilterO  ; // 

us-8tart() ; 

// 

uhile(l) 

{ reading  = us-8ensor-get-attributes-reading(route, attr, modifier) ; 
fx=reading[0] ; fy=  readingCl] ; fz=reading[2] ; 
tx=reading[3] ; ty=  reading [4] ; tz=reading[5] ; 

//  loB,  do  something  with  the  values.... 

} 


in  Hertz 

update  every  100  milliseconds 
start  filter 


//  force 
//  torque 
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D.2  Channel  Interface  Example 

As  suggested,  the  communication  protocol  is  treated  as  a separate  issue  from  language  or  mes- 
saging strategy.  Just  like  the  C language  file  descriptor  construct  separates  the  concept  of  the 
physical  implementation  of  a file  or  a device  from  the  program,  one  could  adopt  a communica- 
tion message  descriptor  to  separate  the  concept  from  the  actual  communication  implementation. 
The  message  descriptor  could  be  used  to  implement: 

— a piece  of  information  that  is  shared  in  memory  and  cyclically  updated, 

— a streamed  interface. 

Below,  one  finds  an  example  of  a possible  interface  that  combines  the  messaging  with  a protocol. 
The  set  of  data  type  cms_msg_t  and  corresponding  functions  cms_open,  cms_send,  cms.close 
constitute  a portion  of  a communication  management  system  (cms). 

moduleAO  { 

cins_msg_t  msg; 

us_tlc_set_travor8e_rate_m8g_t  rate  = 

{ US_TLC_SET_TRAVERSE_SPEED, 

0 } : 

msg. name  = "TPS_T0_TLC:T00L:A" 
msg. protocol  = SHNEN; 
cms_open(Amsg) ; 
speed. value  =30;  //  rpm 
cms_send(msg,  rate); 
cms_close(msg) ; 

In  the  example,  one  opens  a communication  channel  much  like  one  opens  a file  descriptor  within 

C.  In  C,  the  file  descriptor  can  be  to  a device  or  a file.  Within  UTAP  Interface  Framework,  one 
should  assume  that  the  communication  descriptor  should  allow  any  number  of  communication 
protocols,  for  example,  shared  memory  or  INET  sockets. 

D. 3  Configuration  File  Example 

Table  D.l  illustrates  an  example  REMOTE  configuration  file.  Within  the  REMOTE  config- 
uration, one  can  safely  assume  that  single-instance  modules  are  unique,  but  one  may  need  to 
establish  existence.  The  enable  field  defines  whether  a module  exists.  For  example,  a REMOTE 
system  may  only  consist  of  an  operator  joystick  interface  to  the  LOCAL  system.  In  this  case, 
most  modules  in  the  REMOTE  system  would  be  inactive. 

The  multi-instance  modules  require  a superior /subordinate  link  to  establish  the  grouping  rela- 
tionship. The  multi-instance  modules  will  implicitly  be  enabled  if  they  are  linked  to  subordi- 
nates. The  subordinates  are  grouped  according  to  the  UTAP  architecture.  That  is,  one  cannot 
expect  to  group  REMOTE  modules  within  a LOCAL  subordinate  group.  Table  D.2  illustrates 
the  format  required  for  Figure  3 for  the  LOCAL  system  configuration. 

D.4  Example  of  Message  Flow  for  Sample  UTAP  Scenario 

An  example  of  message  traffic  in  a sample  scenario  will  help  to  verify  the  interface  definitions 
made  about  the  tasks,  sensors,  object  models  and  part  features.  Since  UTAP  applications 
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Table  D.l  — Example  Remote  System  Configuration  File 


Module  Set 

Enabled 

Types 

01 

Y 

Panel 

OM,  OC,  OK 

Y 

Vanilla 

TD,  TK,  TDS 

Y 

Teach,  Programmable 

SGD 

Y 

see  [SANCHO] 

ADS 

N 

ss 

N 

PTPS:TPS:A 

Y 

Manipulation 

PTPS:TPS:B 

Y 

Navigation 

PTPS:TPS:C 

Y 

Tooling 

stress  operator-supervised,  telerobotic  activity,  the  operator  panel  is  fundamental  to  assessing 
strengths  and  weaknesses.  A simple  operator  panel  is  given  in  Figure  reffg:  oipanel.  This  panel 
visually  depicts  one  of  many  possible  operator  interface  paradigms.  This  operator  paradigm 
uses  the  display  to  do  feature-based  tooling.  The  operator  chooses  from  the  variety  of  feature 
panels  (shape,  pattern,  edge,  force)  to  select  the  desired  parameters.  It  is  assumed  that  defaults 
could  already  be  registered  on  the  screen  for  a particular  task.  The  operator  would  then  select 
specific  feature  icons  to  modify  and  assist  in  developing  the  feature-based  world  model. 

The  panels  match  the  object  analysis.  For  example,  in  the  Shape  Panel,  the  panel  items  have 
the  following  meaning  - from  the  top  left,  clockwise  around  the  panel:  target  select,  2D  circle, 
2D  rectangle,  straight-line,  3D  cylindrical  volume,  3D  cubic  volume,  obstacle,  and  a 2D  polygon. 
The  pattern  panel  items  correspond  to  horizontal  raster,  vertical  raster,  concentric  circular  fill, 
overlap,  dither,  and  orbital.  The  nozzle  panel  items  correspond  to  density  of  spray  or  flow  rate 
- in  one  possible  data  view.  K one  selects  to  do  an  edge  instead  of  pattern  fill,  the  edge  panel  is 
available  for  this  task.  The  edge  panel  allows  exact  motion  along  the  curvilinear  edge,  a cosine 
weave  pattern  along  the  edge  (e.g.,  for  welding),  and  dither  correspond  to  the  types  of  motion 
along  the  edges  of  the  part  features  discussed  within  the  features  analysis. 

A UTAP  sample  session  is  described  herein  for  a refurbishing  task.  The  operator  turns  on  the 
system.  The  operator  waits  for  a prompt  from  the  system  to  proceed.  The  operator  defines  a 
work  area  by  teaching  the  robot  points  about  the  edges  of  the  work  area.  The  operator  uses 
the  joystick  and  moves  the  robot  to  each  desired  location  and  presses  a button  to  record  the 
location.  The  work  area  is  usually  a default  geometry  (circle,  rectangle).  The  operator  adjusts 
the  parameter  settings  that  are  specific  to  the  process.  Each  process  maintains  a standoff 
distance  though  it  varies  from  process  to  process.  The  operator  presses  a button  to  start  the 
robot.  The  robot  will  move  through  the  taught  geometry.  The  operator  observes  the  process  for 
correct  execution.  During  this  time  the  operator  can  adjust  the  parameters  as  needed.  He  can 
pause  the  process  if  something  is  not  operating  properly  (e.g.,  clogged  sprayer).  The  operator 
can  also  press  an  emergency  stop  button  if  something  is  very  wrong.  When  the  process  is 
complete,  the  operator  inspects  the  results.  If  there  are  areas  that  were  not  done  properly  the 
operator  can  do  a touch-up  operation.  The  operator  can  do  the  touch-up  himself  by  moving  the 
robot  and  controlling  the  tool  or  he  can  define  a work  area  around  the  bad  region  and  have  the 
robot  do  it  as  it  did  the  larger  region.  Once  the  work  area  or  part  is  finished  the  operator  moves 
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Table  D.2  — Example  Local  System  Configuration  File 


Superior  Module  Path 

Subordinate  Module  Name 

Type 

PTPS 

TPS:A 

Manipulation 

TPS:B 

Navigation 

TPS:C 

Toohng 

TPS:A 

TLC:A 

Position,  Force 
or  Compliance,  Impedance 

TPS:B 

TLC:B 

Teleop,  Guided,  Autonomous 

TPS:C 

TLC:C 

Position,  Force,  Impedance 

TLC:A 

ROBOT:A 

ROBOT:B 

SENSOR:A 

TOOL:A 

MANIPULATION 

SENSORrB 

FTS,  IMAGE,  PROBE 

TOOL:B 

VS 

SPRAY 

TLC:A:SENSOR:B 

BEAM  BREAK 

Switch 

TLC:A:TOOL:B: 

GRIPPER 

grasp 

TLC:A:ROBOT:A 

RRC 

position 

TLC:A:ROBOT:B 

ACTIVE  TOOL 

TLC:A:SENSOR:A 

CAMERA 

TLC:A:TOOL:A 

3-FINGER  GRIPPER 

TLC:A:VS 

Proximity 

(don’t  care  if  sonar  or  laser) 

TLC:B: 

ROBOT 

TRANSPORT  (Lift) 

TLC:C 

TOOL:A,  SENSOR:A 

TLC:C:TOOL:A 

ORBITAL  SANDER 

TLC:C:SENSOR:A 

CAMERA  (stationary) 

TLC;C; 

ROBOT,  SENSOR 

TLC:C:ROBOT 

COMPLIANT_ROBOT 

TLC:C:SENSOR 

WRIST  FORCE  SENSOR 

to  the  next  work  area  or  part. 

The  following  message  flow  summarizes  the  correspondence  between  a task  steps  and  message 
traffic  during  a refurbishing  task.  Within  the  following  message  flow  summary,  the  channel 
across  which  the  message  is  transmitted  is  listed  first.  The  transmission  channel  is  labelled 
source.to.destination,  where  source  and  destination  correspond  to  the  communicating  modules. 
Then,  a UTAP  message  follows  optionally  requiring  calling  parameters.  Messages  that  cause 
recursive  action  and  subsequent  messaging  before  the  next  step  can  continue  are  indented. 
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UTAP  REFURBISHING  SYSTEM 


ESTOP 


Figure  D.2  - Example  OI  Control  Panel 
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Table  D.3  — Sample  Session  - init 


HUMAN.TO.OI 

OI.TO.OC 

OI.TO.OM 

OM.TO.OK 

OLTO-TD 

OI.TO.TDS 

TDS-TO.TK 

TDS-TO-OK 

TDS-TO.PTPS 

PTPS.TO.OK 

TDS.TO.TPS.A 

TDS.TO.OK 


TPS.A.TO.TLC.A 

TLC.A.TO.OK 


TLC.A.TO.OK 

TLC.A.TO.OK 

TLC.A.TO.OK 

HUMAN.TO.OI 

OI.TO.TDS 

TDS.TO.TK 

TK.TO.TDS 

TDS.TO.PTPS 

PTPS.TO.TPS.A 

TPS.A.TO.TLC.A 


TLC.A.TO.RSC.A 


powerup 

US.STARTUP(config) 

US.STARTUP(config) 

US.STARTUP(config) 

US.STARTUP(config) 

US.STARTUP(config) 

US.5TARTUP(config) 

TPS.A=US.GET.SELECTIONJD(“SUBSYSTEM.TPS.A”); 

US.STARTUP(config) 

TPS.A=US.GET.SELECTIONJD(“SUBSYSTEM.TPS.A"); 

US.STARTUP(config) 

TLC.A=US.GET.SELECTION-ID(“SUBSYSTEM.TPS.A”); 
RSC.A=US.GET.SELECTIONJD( “ROBOT  A”): 
TC.A=US.GET.SELECTION.ID(“TOOL  A”): 
TC.A=US.GET.SELECTION.ID( “SENSOR  A”): 
SC.B=US.GET.SELECTION.ID(  “SENSOR  B” ): 
US.STARTUP(config) 

RSC. A=US.GET.SELECTION JD(  “ROBOT  A” ): 
US.USE.SELECTION(RSC.A); 

US.STARTUP(config) 

TC. A=US.GET JSELECTION.ID(  “TOOL  A” ) : 
US.USE..SELECTION(TC.A);  US.STARTUP(config) 

SC. A=US.GET-SELECTION  JD( “SENSOR  A” ) : 
US.USE.SELECTION(SC.A);  US.STARTUP(coiifig) 
SC.B=US.GET.SELECTION.ID(  “SENSOR  B” ) : 
US.USE.SELECTION(SC.B);  US.STARTUP(config) 
enters  Name  and  Passwd 
US.TDSXOAD.USER{OPERATOR) 

“ System  Initialization” 

US.USE.SELECTIONJD,  US.TK.GET  JRAMEWORK 
USJ’OSTJRAMEWORK(...) 

US.USE.SELECTION.ID(id  for  SUBSYSTEM.A)  ; 

US.USE  JRAMEWORK(  “defatilts” ) 

US.USE.SELECTION JD(id  for  SUBSYSTEM.A)  ; 
US.USEJ'RAMEWORK( “defaults”)  ; 
US-USE.SELECTION.ID(id  for  RSC.A) 

US.BEGIN.MACRO( “default  setup") 

USXOADJDOF(6); 

USXOADJlEPRESENTATION(EuIer); 
USXOADXENGTH.UNITS{mm); 
US.USE.CARTESIANJVIODE  (ALL); 
US.USE.KINEMATIC.RING(.BASE  — .TOOL  ); 

( “same  as”  US.USE.TOOL.TIP  JIEFERENCE.FRAME();) 
USXOAD.BASEJARAMETERS(...); 

US.USE.SELECTION  JD(id  for  TC.A); 
USXOAD.TOOL-PARAMETERS(....); 

US.END.SELECTION; 

USXOAD.JOINTXIMITS(...); 

USiOAD.VELOCITY.LIMIT(velmax); 

USXOAD.ACCELERATION.LIMIT(accmax); 

USXOAD.TRAVERSEJlATE(tr);  USXOAD.FEED JlATE(fr); 

USJENDJvlACRO 

US_USE.MACRO( “default  setup”); 

US.USE.SELECTION  JD(id  for  robot  servos  A); 
US.BEGINJV1ACR0( “default  setup”); 

usj:.oad.jointximit(...); 

USXOAD.VELOCITYXIMIT(...); 

USXOADJ"ID.GAIN(p,i,d); 

US.USEJVBSOLUTE.POSITIONJVIODE() 

US.USEJIADIAN.UNITSO; 

US.USEJIDO; 

“Closed  loop  control  - feedback  every  10  milliseconds” 
US.GETJOSITION(ACTUAL,  10ms); 

usj:ndjviacro; 

usj:nd.selection; 
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Table  D.4  - Start  Teleoperation 


HUMAN.TO.OI 

OLTO.TDS 

TDS.TO.TK 

TK.TO.TDS 

TDS.TO.PTPS 

PTPS.TO.TPS.A 

TPS.A.TO.TLC.A 


HUMAN.TO.OI 

OI.TO.TDS 

TDS.TO.TPS.A 

TPS.A.TO.TLC.A 

TLC.A.TOJISC.A 


TLC.A.TO.SEN.A 


HUMAN.TO.OI 

OI.TO.TLC.A 


OI.TO.TLC.A 

TLC.A.TOJISC.A 

RSC.A.TO.TLC.A 


HUMAN.TO.OI 

OI.TO.OC 

OC.TO.OK 

OC.TO.OK 


HUMAN.TO.OI 

OI.TO.OC 

OC.TO.OK 


OC.TO.OK 

HUMAN.TO.OI 

OI.TO.TDS 

TDS.TO.TPS 

TPS.TO.TLC 


“Assume  lift  in  place” 

“selects  subsystem  A to  do  shared  control  to  teach  positions” 

US.SELECTJ^ODE(shared,  x-axis) 

US.USE.SELECTIONJD 

US.TK.GET  J'RAMEWORK(  “standoff  teach” ) 

USJOSTJ'RAMEWORK(...) 

US.USE.SELECTIONJD(id  for  SUBSYSTEM.A); 

US.USE  J'RAMEWORK(  “standoff  teach” ) 
US.USE.SELECTION  JD(id  for  SUBSYSTEM.A); 

US.USE J^RAMEWORK(“8t£indoff  teach”)  ; 
US.USE.SELECTION  JD(id  for  RSC.A) 

US.BEGIN  JVIACRO(  “standoff  teach” ) 

US.USE  JVlACRO(  “defaults” ) ; 

US.START.STANDOFF JVlOTION(  “x” , 300mm); 
US.STARTJVlANUAL.MOTION(ALL  XjVXIS); 
USJINDJVIACRO 

US.USE J4ACRO( “standoff  teach”); 

push  start  button,  waits  for  robot  to  home,  then  use  joystick 

US.START 

US.START 

USJIOME;  US.START; 

US.USE  JVIACRO  ( “default” ) ; 

USJIOME;  //  put  values  in,  for  eventual  motion 
US  J;NABLE(ALL);  //  enable  servos 
US.CLEAR.BRAKES(ALL); 

US.START;  //  software  start 
US.START.MACRO(  “range” ) 
USXOAD.SAMPLING.SPEED(speed) 
USXOADJREQUENCYCfreq) 

“more  sensor  inits?” 

USJINDJVIACRO 
US.USE  J^ACRO(  “range” ) 

“Repeated  Joystick  Motion” 

6 DOF  joystick  motion 

US.BEGIN.BLOCK;  US.ADJUSTJ\.XIS(ALL,  values); 
USJ;ND3L0CK; 

“Monitors  for  standoff  distance” 

U S .S  ET  J*  O S ITIO  N ( desired. values ) 
US.SETJ’OSITION(desires.values); 
USJ’OSTJOSITION(actual.values) 

“Calibrate  Comer  of  Rect” 

marks  comer  of  feature  (where  feature  = shape  + pattern) 
US.SET.CALIB(featurejorigin,  rect); 
now=US.GETJ’OSITION(actual); 
rect.x=now.y;  rect.y=  now.z; 

obj=US.CREATE.OBJECT(name,  part.t,  rect,  raster); 


“Move  to  Second  Point  using  Joystick  Motion  - see  above” 
“Define  Second  Comer” 

marks  2nd  comer  of  featme  (where  feature  = shape  + pattern) 

US.SET.CALIB(featurejoffset,  rect); 

now=US.GETJ»OSITION(actual); 

obj.xlength  = rect.x  - now.y; 

obj.ylength  = rect.y  - now.z; 

USJVIODIFY.OBJECT(obj); 

“User  finished  teaching” 
presses  button  to  end  teaching 
US.STOP 
US.STOP 

US.BEGINJVIACRO( “standoff  teach  halt”) 
US.STOPJtlANUAL.MOTION 
US-STOP.STANDOFFJtlOTION 
USJINDJVIACRO 

US.USE.MACRO( “standoff  teach  halt”) 
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Table  D.5  - Start  Automated  Process 


HUMAN.TO.OI 

OI-TO.TDS 

OI-TO.TDS 

TDS.TO.TK 

TK.TO.TDS 

TDS-TOJTPS 

PTPS.TO.TPS.A 

TPS.A.TO.TLC.A 


TLC.A.TO^EN.A 


TLC.A.TO.TOOL.A 


“Start  Automated  Process” 

“human  presses  button  to  get  into  process  control  screen” 
US^ELECTJVIODE(supervised,  aU  ) 
US^ET.TDS-SELECT-OPERATION(  “strip”) 
US-USE^ELECTION-ID,  US.TK.GET-FRAMEWORK(  “strip” ) 
US-POST-FRAMEWORK(...) 

US.USE-SELECTION.ID(id  for  SUBSYSTEM.A)  ; 
US.USEJRAMEWORK(  “standoff  teach” ) 
US-USE^ELECTION-ID(id  for  SUBSYSTEM.A)  ; 
US.USEJ'RAMEWORK( “standoff  teach”)  ; 
US-USE-SELECTION  JD(id  for  RSC.A) 

US_BEGIN_MACRO( “standoff  teach”) 

US.USEJVlACRO(  “defaults” ); 
US^TART-STANDOFF-MOTION(  “x” , 300mm); 
US^TART-MANUAL.MOTION(ALL  X-AXIS); 
USJIND-MACRO 

US_USE_MACRO( “standoff  teach”); 

USJSTART-M  ACRO(  “range” ) 

US_LOAD.SAMPLING.SPEED(speed) 

USJ:.OAD-FREQUENCY(freq) 

US-ENDJVIACRO 
US.USE-MACRO(  “range” ) 

US_FLOW_LOAD_PARAMETERS(flow_rate,  beam,  stream) 


HUMAN.TO.OI 

OI.TO-TDS 

TDS.TOJTPS 

PTPS.TO.TPS.A 

TPS.A.TO.TLC.A 

TLC.A.TO.SEN.A 

TLC.A.TO.TOOL.A 

TLC.A.TO.ROBOT.A 


SEN.A.TO.TLC.A 

TLC.A.TOJIOBOT.A 

ROBOT.A.TO.TLC.A 


“humein  presses  button  on  OI  to  start  process” 

USJSTARTO; 

US.USE.SELECTION-ID(id  for  SUBSYSTEM.A)  ; US.START(); 
US.USE.SELECTION  JD(id  for  SUBSYSTEM.A)  ; US.START(); 
US-USEJSELECTION  JD(id  for  RSC.A) 

USJSTARTO; 

US.ENABLE() 

US.START(); 

usj:nable(); 

US.START(); 

USJINABLEO; 

US.CLEAR.BRAKES(); 

US.START(); 

“Subsystem  TLC.A  Series  of  commands  to  do  raster  path” 

US  J’OST-READING( “r£inge  reading” ) 

US J^XIS-SERVO-SETJOSITIONl “desired  position”); 

US  J*OST-READING( “actual  position”) 

US.GENERIC.STATUS  JlEPORT(executing,  progressing) 


US.GENERIC.STATUS.REPORT(fuushed,  succeeded); 
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Annex  E 

(informative) 

Related  Standards 


E.l  RS274D 

EIA/RS274D  is  a standard  programming  language  that  is  intended  to  serve  as  a uniform  interface 
for  command  and  control  of  numerically  controlled  machine  tools. 


E.2  RS441 

The  UTAP  operator  interfaces  will  use  the  RS441  existing  standard  to  define  operator  control 
and  modes  of  operation. 

E.3  POSIX 

ISO/IEC  9945  and  IEEE  1003  standard  series  are  intended  to  define  a standard  portable  op- 
erating system  interface  and  environment  to  support  application  portability  at  the  source-code 
level.  Areas  of  POSIX  standardization  efforts  include  definitions  for  system  services;  user  in- 
terface (shell)  and  associated  commands;  real-time  extensions;  networking  protocols;  graphical 
interfaces;  data  base  management  system  interfaces;  object  and  binary  code  portability;  sys- 
tem configuration  and  resource  availability;  behavior  of  system  services  for  systems  supporting 
concurrency  within  a single  process. 

E.4  lEC  1131-3 

Parent  Task  Program  Sequencing  input  shall  use  IEC1131  Part  3 as  a the  interface  language  to 
describe  any  parallel  or  simultaneous  behavior. 

lEC  1131  Part  3 specifies  the  syntax  and  semantics  of  a unified  suite  of  programming  languages 
for  Programmable  Controllers  (PCs).  These  consist  of  two  textual  languages,  IL  (instruction 
lists)  and  ST  (Structured  Text)  and  two  graphical  languages  LD  (Ladder  Diagram)  and  FED 
(Function  Block  Diagram).  Sequential  Function  Chart  (SFC)  elements  are  defined  for  struc- 
turing the  internal  organization  of  PC  programs  and  function  blocks  written  in  one  of  the  4 
languages. 

The  SFC  elements  provide  a means  of  partitioning  a PC  program  organization  unit  into  a set 
of  steps  and  transitions  inter-connected  by  directed  links.  Associated  with  each  step  is  a set  of 
actions,  and  with  each  transition  is  associated  a transition  condition.  Because  SFC  elements 
require  storage  of  state  information,  the  only  program  organization  units  which  can  be  structured 
using  these  elements  re  function  blocks  and  programs.  Configuration  elements  are  defined  which 
support  the  installation  of  PC  programs  into  PC  systems  and  include  configurations,  resources, 
tasks,  global  variables,  and  access  paths.  A configuration  contains  one  or  more  resources  (e.g., 
CPU)  each  of  which  may  contain  one  or  more  tasks  and  programs 
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E.5  ANSI/RIA  R15-06-1992 

The  American  National  Standard  (ANSI)  for  Industrial  Robots  and  Robot  Systems  Safety  Re- 
quirements, ANSI/RIA  R15-06-1992,  Sponsor:  RIA  was  approved  - August  19,  1992.  The 
purpose  of  this  standard  is  to  provide  guidelines  for  industrial  robot  manufacture,  remanufac- 
ture and  rebuild;  robot  system  installation;  and  methods  of  safeguarding  to  enhance  the  safety 
of  personnel  associated  with  the  use  of  robots  and  robot  systems.” 

E.6  EIA  Standard  RS-267-A 

This  standard  comply  with  terminology  defined  in  EIA/RS267-A  for  “Axis  and  Motion  Nomen- 
clature for  Numerically  Controlled  Machines.” 

E.7  XDR 

Public-domain  set  of  routines  to  allow  C programmers  to  describe  arbitrary  data  structures  in  a 
machine-independent  fashion.  Data  for  remote  procedure  calls  (RPC)  are  encoded  and  decoded 
using  XDR.  Can  be  used  for  other  heterogeneous  platform  communication  as  well. 
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Annex  F 

(informative) 

Target  Applications 


The  architecture  has  been  developed  for  general  aircraft  maintenance  and  remanufacturing  ap- 
phcations.  Among  the  many  applications  in  aircraft  maintenance  and  remanufacturing,  three 
target  applications  were  specifically  addressed:  stripping  paint  from  the  skin  of  an  aircraft; 
surface  finishing;  and  advanced  cutting.  The  potential  application  of  telerobotics  to  these  ap- 
plications is  described  in  this  section. 

F.l  Paint  Stripping 

One  way  of  stripping  paint  from  the  skin  of  an  aircraft  is  to  blast  Plastic  Media  Bead  (PMB) 
on  the  painted  surface  of  the  aircraft.  The  operator  applies  PMB  to  a targeted  surface  area 
with  a certain  pressure,  using  the  blast  gun  located  at  a designated  distance  from  the  surface 
with  a certain  orientation  (relative  to  the  tangential  plane  of  the  surface).  To  cover  the  entire 
surface  area  of  an  aircraft,  a mobile  platform  or  a telecrane  is  used  to  move  the  operator  around 
the  aircraft.  More  specifically,  the  paint  stripping  task  requires  the  following  subtasks  and 
considerations: 

a)  The  positioning  of  the  mobile  platform  at  a location  that  allows  the  operator  to  cover 
the  new  targeted  area  with  sufficient  dexterity. 

b)  The  maintaining  of  the  designated  distance  and  orientation  of  the  gun  with  respect  to 
the  blasting  surface,  while  following  the  proper  trajectory. 

c)  The  controlling  of  the  speed  of  the  gun  based  on  the  visual  monitoring  of  the  progress 
of  stripping.  Due  to  the  possible  difference  in  paint  thickness,  without  proper  monitoring  of 
the  progress  of  stripping  for  adjusting  speed  and  pressure  of  blast,  over-stripping  as  well  as 
under-stripping  may  result.  The  skill  of  the  operator  is  important  for  this  task. 

d)  The  finishing  up  process  to  strip  under-stripped  areas. 

It  is  expected  that  the  application  of  telerobotics  to  the  above  paint  stripping  task  can  bring 
forth  the  following  advantages: 

a)  The  operator  can  stay  in  a remote  location  protected  from  pollutant  contamination 
during  operation,  such  that  not  only  safety  but  also  efficiency  in  task  execution  can  be 
enhanced. 

b)  The  machine  may  be  better  in  accuracy  and  consistency  for  maintaining  the  distance 
and  orientation  of  the  gun  with  respect  to  the  blasting  surface. 

c)  The  larger  workspace  of  manipulators  can  be  exploited. 

d)  The  advanced  visual  sensors  and  displays  may  provide  the  operator  with  more  effective 
tools  for  inspecting  the  progress  of  stripping. 
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Based  on  the  above  observations,  we  can  construct  the  following  telerobotics  system  for  the 
paint-stripping  operation: 

a)  A dextrous  manipulator  replaces  a human  operator  in  the  immediate  worksite. 

b)  The  human  operator  is  able  to  manually  control  the  manipulator. 

c)  The  human  operator  is  given  visual  displays  for  monitoring  the  progress  of  paint  strip- 
ping. The  visual  displays  may  be  based  on  cameras  mounted  on  the  manipulator  or  based 
on  another  manipulator  carrying  cameras  and  light  sources  and  other  sensors. 

d)  Sensor-based  automatic  operations  are  provided  for  maintaining  the  distance  and  ori- 
entation of  the  gun  automatically. 

e)  The  manipulator  trajectories  can  be  determined  by  the  human  operator,  or  by  the 
system,  or  by  a combination  of  both.  The  trajectories  generated  by  the  system  can  be  from 
the  off-line  interactive  graphic  simulation  or  from  a functional  form  in  relation  to  the  known 
geometric  model  of  the  target  surfaces.  The  capability  of  combining  the  manual  and  system 
trajectories  allows  the  integration  of  the  operator  skill  in  reacting  to  the  visual  monitoring 
of  the  task  progress. 

f)  To  execute  the  system  generated  trajectories,  the  manipulator  should  be  registered  on 
a predetermined  location  or  localized  with  respect  to  the  geometric  model  of  the  surface. 

g)  The  application  program  developer  should  be  provided  with  an  iconic  and  menu-driven 
interface  that  allows  easy  programming.  That  is,  programming  is  done  by  configuring  the 
existing  software  modules  through  an  iconic  and  menu-driven  interactive  computer  interface. 

F.2  Telerobotic  Surface  Finishing 

Surface  finishing  is  an  important  task  in  aircraft  maintenance  and  remanufacturing.  The  dam- 
aged or  corroded  portion  of  the  aircraft  skin  is  patched  or  replaced.  Uneven  surfaces  are 
ground  smooth.  Telerobotics  technology  can  be  used  for  automatically  controlling  the  con- 
tact force/torque  of  a tool  during  surface  finishing  while  maintaining  the  designated  tool  angles 
with  respect  to  the  surface  normal,  without  a priori  knowledge  of  part  geometry,  through  shared 
control.  The  tool  path  may  be  generated  either  manually  by  the  operator  or  from  the  preassigned 
trajectory  generated  by  off-line  programming.  The  tool  path  may  be  subject  to  certain  artificial 
motion  constraints.  Note  that,  in  the  case  of  manual  operation,  the  contact  force/torque  needs 
to  be  guarded  so  as  not  to  exceed  the  maximum  allowable  force/torque.  Similar  to  the  paint 
stripping  task,  the  operator  should  monitor  the  progress  of  surface  finishing  based  on  visual  and 
graphic  displays,  so  that  the  operator  can  fine-tune  or  modify  the  tool  path  accordingly. 

The  surface  finishing  task  seems  quite  different  from  the  paint  stripping  task.  However,  a 
common  telerobotics  architecture  can  be  used.  This  is  because  both  tasks  are  based  upon 
the  shared  and  cooperative  control  between  human  and  machine,  in  spite  of  the  fact  that  the 
surface  finishing  task  depends  on  force/torque  sensing  whereas  the  paint  stripping  task  depends 
on  proximity  sensing  for  sensor-based  automatic  operations.  The  only  major  difference  is  that 
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the  path  fusion  in  surface  finishing  requires  consideration  of  the  increment  of  force  and  torque 
together  with  the  increment  of  path. 

F.3  Telerobotic  Advanced  Cutting  System 

The  maintenance  and  remanufacturing  of  aircraft  requires  cutting  of  all  types  of  material  in  many 
different  shapes  and  sizes.  Telerobotics  technology  can  provide  shared  control  for  generating  the 
tool  trajectory  in  advanced  cutting.  The  trajectory  may  be  specified  by  prestored  data  generated 
by  off-line  programming  or  by  the  operator  through  a hand  controller  or  by  visual  servoing  of 
a marked  path  on  the  object  surface.  The  system  automatically  regulates  the  surface  stand- 
off/separation and  the  tool  orientation  at  the  designated  values,  as  well  as  imposing  certain 
artificial  constraints  on  the  trajectory.  The  change  of  tools  and  the  initialization  of  system  need 
to  be  incorporated  into  the  system. 

The  telerobotics  architecture  for  advanced  cutting  is  basically  same  as  that  of  paint  stripping 
and  surface  finishing.  A unique  feature  is  the  integration  of  visual  servoing  based  on  vision 
sensors. 
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Annex  G 

(informative) 

API  Issues 


Defining  the  range  of  capability  expected  of  the  API  mechanism  is  problematic.  One  cannot 
arrive  at  the  perfect  solution  that  is  exceedingly  complex  or  prohibitively  expensive.  Instead, 
compromises  must  be  made  in  arriving  at  an  API  mechanism  that  resolve  issues  for  flexibility 
and  extensibility.  Issues  that  the  UTAP  API  will  have  to  resolve  (noted  by  the  (Unresolved) 
after  the  item)  or  have  been  resolved  (noted  by  the  (Resolved)  after  the  item)  include 

G.l  Messages,  Macros  and  Naming 

The  UTAP  interfaces  will  define  a broad  API.  Yet,  it  would  be  impossible  to  anticipate  and 
explicitly  enumerate  every  possible  control  and  sensing  algorithm  and  parameter.  For  example, 
suppose  a better  control  algorithm  is  developed,  how  will  the  interface  permit  the  selection 
of  this  algorithm?  Further,  suppose  an  additional  compensation  parameter  could  be  specified 
within  the  servo  control.  How  wiU  the  system  adapt  to  the  additional  parametric  capability? 
Will  macro  programmability  of  an  interface  be  allowed,  and  how  would  this  be  achieved? 


G.2  Integration 

One  desires  the  ability  to  do  on-line  configuration  and  assignment  of  modules  and  connect  the 
module  communication.  The  ability  to  CONNECT/DISCONNECT  to  actual  devices  (such  as 
actuators  or  sensors)  or  virtual  devices  (such  as  other  modules)  is  provided  by  the  UTAP  API 
definitions.  Once  connected,  one  must  be  concerned  with  communication  data  flow. 

The  connection  for  command  communication  (such  as  a superior-subordinate  connection)  is 
straightforward.  In  this  case,  one  sends  goal-action  commands  to  a subordinate  and  awaits 
results.  However,  model-driven  data  communication  (peer-to-peer)  is  not  directly  apparent.  For 
example,  when  you  add  a new  sensor  to  your  system,  how  do  you  pump  this  sensor  data  into  an 
Trajectory  Generation  module  for  dynamic  path  modification.  Receiving  data  from  a connection 
is  straightforward.  One  connects  to  the  module,  queries  a variable  and  reads  the  updates  that 
the  module  provides.  Unresolved  is  the  application  of  external  data  within  a module.  UTAP 
API  provide  externally-accessible  model-driven  variables  within  UTAP  API  modules  for  update 
- such  as  overrides  or  offsets  - to  allow  integration  of  user-customized  or  third-party  sensor-based 
control.  (The  question  remains  whether  enough  externally-accessible  model-driven  variables  will 
be  defined.) 

G.3  Definition  Style 

The  style  of  the  API  definitions  is  of  considerable  importance.  One  could  use  ASN.l  or  the 
STEP  modeling  language  EXPRESS  to  develop  a rigorous  definition  of  the  interfaces.  For  aU 
indications  from  UTAP  API  members,  this  is  be  too  cumbersome  and  approach.  One  could  use 
BNF,  source  headers  files,  or  any  syntax  definition  mechanism  to  define  a grammar  that  each 
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channel  accepts.  There  is  a trade-ofF  between  interface  language  complexity  and  performance. 
This  is  an  issue  of  major  importance  that  has  been  discussed  but  every  solution  has  baggage. 

This  Definition  Style  issue  also  must  resolve  the  problem  of  differentiating  between  cyclically 
executing  processes  (such  as  servo  or  discrete  logic  module  or  trajectory  generator)  and  asyn- 
chronous processes  (such  as  Part  Program  Interpreter  and  the  Task  Coordination  Module.)  The 
problem  is  that  a definition  consisting  of  a set  of  function  calls  alone  is  not  sufficient  to  describe 
the  a cyclically  executing  or  event-driven  API.  One  needs  to  understand  the  trigger  mechanism 
that  drives  the  event  (such  as  an  external  clock  or  a synchronization  trigger  from  a cooperating 
module.)  This  issue  has  been  discussed  but  no  final  resolution  has  been  forwarded. 

G.4  Variable  Length  Arrays 

One  of  the  problems  that  arises  defining  interfaces  concerns  the  handling  of  variable  length 
arrays.  Unless  one  rejects  the  notion  of  flexibility,  an  interface  should  not  preordain  a fixed 
array  size  for  any  interface.  One  would  find  passing  5 axis  values  to  a 3-axis  miU  less  than 
intuitive.  Heaps  wiU  be  used  to  resolve  this  problem. 

G.5  Units  and  Representation 

It  is  possible  to  mandate  Standard  International  Units.  Yet,  this  can  cause  problems  since 
one  prefers  to  use  units  that  are  natural  for  the  application  (millimeters,  inches,  etc.)  For 
many  robotics  and  automation  applications,  the  millimeter  is  the  natural  and  intuitive  way 
of  thinking  about  a problem.  There  should  be  no  reason  to  contradict  the  natural  reasoning 
process.  Further,  NASA  mandates  foot  and  pounds  as  the  units  of  choice.  Thus,  one  needs 
conversion.  One  has  to  make  the  decision  as  to  whether  the  conversion  is  done  by  the  sender  or 
the  receiver.  In  the  vendor  marketplace,  a commercial  product  module  should  provide  conversion 
utilities. 

UTAP  modules  shall  state  acceptable  measurement  units  within  its  interfaces.  The  range  of 
acceptable  measurements  units  may  become  broader  as  the  application  requirements  dictate. 
For  example,  an  automated  horse  may  require  the  addition  of  the  furlong  distance  as  an  interface 
measurement  unit. 

The  default  units  shall  be  SI,  and  are: 

From  a standards  aspect,  data  exchange  between  modules  is  designed  to  be  in  a neutral  rep- 
resentation. However,  selection  of  the  correct  neutral  representation  is  also  problematic.  The 
UTAP  modules  shall  support  API  definitions  with  selectable  representation  as  a part  of  the 
mode  control. 

NOTE  1 - The  UTAP  interfaces  include  the  representation  measurement  units  of  an  interface  item. 
Incompatibility  among  like- representation,  dissimilar-units  interfaces  will  be  resolved  by  providing 
use_measurement_units  or  use_representation_type  messaging.  If  the  module  does  not  support  the 
measurement  units  or  representation  types  that  you  desire,  the  programmer  must  perform  the  con- 
version. It  is  assumed  that  more  robust  modules  will  be  better  able  to  handle  a broader  variety  of 
representation  units  and  be  ultimately  more  commercially  viable.  For  example,  a trajectory  inter- 
face may  accept  trajectory  position  descriptions  in  millimeters  or  meters  or  even  inch  length  units. 
Or  the  trajectory  may  accept  orientation  represented  as  Euler  angles  in  degrees  or  radians  or  as 
elements  in  a Homogeneous  Matrix  representation. 
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Table  G.l  - Parameter  and  Units 


Distance  or  Length  or  Position- 

Velocity- 

Acceleration- 

Jerk- 

Angular  measurement- 
Forces- 
Torques- 
Light- 
Viscosity- 
Humidity- 
Temperature- 
Noise- 


Meters 

Meters/Second 

Meters/Second^ 

Meters/Second^ 

Radians 

Newtons 

NewtonMeter 

Lumen 

millipascalSecond  (mPa  S) 
Grams/Meter^  “That’s  grams  of  water” 
Celsius 
Decibel 


G.6  Selection 

Multiple  subordinate  modules  to  be  controlled  by  one  superior  module  is  possible.  Because 
of  the  existence  of  alternatives,  some  messages  to  a subordinate  can  be  ambiguous  as  to  their 
intent.  In  the  case  of  multiple  axes  of  control,  one  must  resolve  the  destination  for  which  axis 
the  command  is  intended.  The  framework  will  provide  a device/module  naming  convention  but 
the  selection  mechanism  is  unresolved. 


G.7  Parameterization 

At  opposite  ends  of  the  spectrum  is  a programming  facility  with  a large  set  of  functions  and 
fixed  parameters  versus  a programming  facility  with  small  set  of  functions  and  a wider  range 
of  arguments.  The  information  content  is  the  same.  Yet,  the  presentation  and  programming  is 
different.  As  for  comprehension,  there  are  arguments  for  and  against  both  styles.  For  example, 
source  is  given  below  for  the  range  of  styles. 

•define  IHL_SERVO_SET_ABS_POSITIOI  251 
struct  nml_8ervo_8et_ab8_po8ition_in8g_t  { 
int  msgid ; 

double  *joint_position; 

}; 

•define  IML_SERVO_SET_REL_POSITIOI  252 
struct  nml_8ervo_8et_rel_position_msg_t  { 
int  msgid ; 

double  • joint_position ; 

}; 


•define  IHL.SERVO.JOG  257 
struct  nml_8ervo_jog_msg_t  { 
int  msgid; 
int  axis; 
double  speed; 

}; 


•define  IHL.SERVO.ADJUST.AXIS  655 
struct  U8_tlc_adjust_axi8_msg_t  { 
int  msgid ; 
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int  axis;  //  axis  mask 

double  eincrement;  //if  amount^O,  system  decides 


Style  2:  Embed  modes: 

•define  1ML_SERV0_SET_P0SITI0I  251 

struct  nml_servo_8et_position_msg_t  { 
int  msgid; 
enum  {absolute, 
relative , 
incremental , 

jog,  //  may  not  belong 
} mode ; 

double  •update; 

}; 

To  further  cloud  the  issue  one  can  turn  both  the  mode  and  the  parameter  into  arguments.  For 
example,  one  can  set  both  the  mode  and  parameter  type  be  it  position,  velocity  or  acceleration. 

Style  3:  Arguments 

•define  IML.SERVO_SET_ VALUE  251 
struct  nml_servo_set_msg_t  { 
int  msgid; 
enum  {absolute, 
relative , 
incremental , 

jog,  //  may  not  belong 
} mode ; 

enum  {position, 
velocity, 
acceleration, 

} parameter; 
double  ^update; 

}; 

The  last  case  is  more  concise,  however,  unless  all  combinatorial  arguments  states  are  valid,  illegal 
and  illogical  messages  can  be  formed.  For  example,  does  jogging  the  acceleration  make  sense? 
The  UTAP  interfaces  are  currently  defined  with  a larger  set  of  functions  to  allow  scaling  within 
this  mechanism,  although  discussions  are  ongoing  as  to  the  efficacy  of  this  method. 

G.8  Aggregation  Model 

One  of  the  issues  effecting  the  specification  of  open  architectures  is  the  approach  to  connecting 
modules. 

— Consistent  approach  wherein  explicit  module  exists  to  translate  from  one  level  of  func- 
tionality to  another  level  of  functionality.  This  module  may  have  zero  (or  phantom/hidden) 
functionality,  in  that,  its  only  capability  is  to  translate  from  a representation  at  a higher 
level  of  abstraction  into  representation  at  a lower  level  of  abstraction. 

The  major  benefit  to  this  approach  is  a consistent  paradigm  that  simplifies  interfaces  between 
modules  to  a more  manageable  set  and  offers  explicit  scalability  and  interoperability,  in  that, 
a direct  swap  of  modules  without  “rewiring”  can  be  used  to  improve  performance. 
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- Free-wiring  allows  interface  traffic  from  a high  level  of  abstraction  to  any  low  level  of 
abstraction.  Thus,  not  all  modules  are  necessary  when  building  a system.  However,  this 
method  assumes  that  a higher  level  module  understands  the  needs  and  representation  of  a 
lower  level  module.  The  drawback  is  that  upgrading  the  controlling  by  adding  modules  to 
improve  capability  is  not  straightforward. 
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Annex  H 

(normative) 

Interface  Descriptions 


The  interfaces  were  defined  as  a set  of  messages.  Each  message  has  an  unique  numeric  identifier 
and  data  structure  defining  parameter  values.  This  annex  contains  the  list  of  interface  messages 
sorted  by  module  by  type  and  alphabetically,  as  well  as  the  current  interface  definitions. 

The  C/C++  language  was  used  to  define  messages.  This  annex  gives  source  listings  of  the 
header  files  used  to  define  the  interfaces.  The  header  files  are  given  in  the  following  order: 

— utap -disclaimer. h 

— generic-defs.h 

— utap-classification.h 

— utap -info -model,  h 

— utap -protocol. h 

— utap-data-defs.h 

— utap -interfaces. h 

— utap-api.h 

The  interfaces  defined  with  API  function  calls  were  generated  by  a shell  script  that  translated 
the  messages  data  structures  into  function  prototypes.  The  enum  and  union  C++  constructs 
did  not  have  direct  mapping  within  the  calling  function,  so  placeholders  were  used. 

The  information  models,  messages,  and  function  prototypes  in  the  header  files  were  compiled 
with  a GNU  gcc  version  2.5.8  a variant  of  C++.  The  code  may  look  like  C,  but  it  is  actually 
C++. 
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H.l  Interface  List 

UTAP_IITERFACE_DEFIIITIOIS 

GEIERIC 

US.STARTUP 

US.SHUTDOWI 

US.RESET 

US.EIABLE 

US.DISABLE 

US.ESTOP 

US. START 

US.STOP 

US. ABORT 

US.HALT 

US. HIT 

US.HOLD 

US.PAUSE 

US.RESUHE 

US. ZERO 

US.BEGH.SIIGLE.STEP 

US.IEXT.SIIGLE.STEP 

US.CLEAR.SIIGLE.STEP 

US.BEGII.BLOCK 

US.EID.BLOCK 

US.BEGII.PLAI 

US.EID.PLAI 

US.USE.PLAI 

US.BEGII.HACRO 

US.EID.HACRO 

US.USE.HACRO 

US.BEGII.EVEIT 

US.EID.EVEIT 

US.MARK.BREAIPOIIT 

US.NARK.EVEIT 

US.GET.SELECTIOI.ID 

US.POST.SELECTIOI.ID 

US.USE.SELECTIOI 

US.USE.AXIS.fUSK 

US.USE.EXT.ALGORITHH 

US.LOAD.EXT.PARAHETER 

US.GET.EXT.DATA.VALUE 

US_POST.EXT.DATA. VALUE 

US.SET.EXT.DATA.VALUE 

US.LOAD.STATUS.TYPE 

US.LOAD.STATUS.PERIOD 

US.GEIERIC.STATUS.REPORT 

ERRORS 

US.ERROR.COMfttlD.IOT.IHPLEHEITED 

US.ERROR.CONHAID.EITRY 

US.ERROR.DUPLICATE.IAME 

US.ERROR.BAD.DATA 

US.ERROR.IO.DATA.AVAILABLE 

US.ERROR.SAFETY.VIOLATIOI 

US.ERROR.LIMIT.EXCEEDED 

US.ERROR.OVER.SPECIFIED 

US.ERROR.UIDER.SPECIFIED 

AXIS.SERVO 

US.AXIS.SERVO.USE.AIGLE.UIITS 

US.AXIS.SERVD.USE.RADIAI.UIITS 

US.AXIS.SERVO.USE.ABS.PDSITIOI.MODE 

US.AXIS.SERVO.USE.REL.POSITIOI.MODE 

US.AXIS.SERVO.USE.ABS.VELOCITY.MODE 

US.AXIS.SERVO.USE.REL.VELOCITY.MODE 

US.AXIS.SERVO.USE.PID 

US.AXIS.SERVO.USE.FEEDFORWARD.TORQUE 

US.AXIS.SERVO.USE.CURREIT 


US.AXIS.SERVO.USE.VOLTAGE 

US.AXIS.SERVO.USE.STIFFIESS 

US.AXIS.SERVO.USE.COHPLIAICE 

US.AXIS.SERVO.USE.IMPEDAICE 

US.AXIS.SERVO.START.GRAVITY.COHPEISATIOI 

US.AXIS.SERVO.STOP.GRAVITY.COHPEISATIOB 

US.AXIS.SERVO.LOAD.DOF 

US.AXIS.SERVO.LOAD.CYCLE.TIHE 

US.AXIS.SERVO.LOAD.PID.GAII 

US.AXIS.SERVO.LOAD.JOIIT.LIHIT 

US.AXIS.SERVO.LOAD.VELOCITY.LIMIT 

US.AXIS.SERVO.LOAD.GAII.LIHIT 

US.AXIS.SERVO.LOAD.DAMPIIG.VALUES 

US.AXIS.SERVO.HOME 

US.AXIS.SERVO.SET.BRAKES 

US.AXIS.SERVO.CLEAR.BRAKES 

US.AXIS.SERVO.SET .TORQUE 

US.AXIS.SERVO.SET.CURREIT 

US.AXIS.SERVO.SET.VOLTAGE 

US.AXIS.SERVO.SET.POSITIOS 

US.AXIS.SERVO.SET.VELOCITY 

US.AXIS.SERVO.SET.ACCELERATIOI 

US.AXIS.SERVO.SET.FORCES 

US.AXIS.SERVO.JOG 

US.AXIS.SERVO.JOG.STOP 

TOOL 

US.SPIIDLE.RETRACT.TRAVERSE 

US.SPIIDLE.LOAD.SPEED 

US.SPIIDLE.START.TURIIIG 

US.SPIIDLE.STOP.TURIIIG 

US.SPIIDLE.RETRACT 

US.SPIIDLE.ORIEIT 

US.SPIIDLE.LOCK.Z 

US.SPIIDLE.USE.FORCE 

US.SPIIDLE.USE.IO.FORCE 

US.FLOW.START.MIST 

US.FLOW.STOP.KIST 

US.FLOW.START.FLOOD 

US.FLOW.STOP.FLOOD 

US.FLOU.LOAD.PARAHETERS 

SEISOR 

US.START.TRAISFORH 

US.STOP.TRAISFORM 

US.START.FILTER 

US.STOP.FILTER 

US.SEISOR.USE.HEASUREMEIT.UIITS 

US.SEISOR.LOAD.SAMPLIIG.SPEED 

US.SEISOR.LOAD.FREQUEICY 

US.SEISOR.LOAD.TRAISFORM 

US.SEISOR.LOAD.FILTER 

US.SEISOR.GET.READIIG 

US.SEISOR.GET.ATTRIBUTES.READIIG 

US.VECTOR.SEISOR.GET.READIIG 

US.FT.SEISOR.POST.READIIG 

US.SCALAR.SEISOR.POST.READIIG 

US.VECTOR.SEISOR.POST.READIIG 

US_2D_SEIS0R_L0AD_ARRAY_PATTERI 

US_2D_SEIS0R.USE_ARRAY_TYPE 

US_2D_SEIS0R_GET_READIIG 

US.2D.SEIS0R_P0ST_READIIG 

US.HAGE.USE.FRAHE.GRAB.MODE 

US.IMAGE.USE.HISTOGRAH.HODE 

US.IHAGE.USE.CEITROID.HODE 

US.IMAGE.USE.GRAY.LEVEL.HODE 

US.IHAGE.USE.TRESHOLD.HODE 

US.IMAGE.COMPUTE.SPATIAL.DERIVATIVES.MODE 
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US_IMAGE_C0I1PUTE.TEMP0RAL_DERIVATIVES_M0DE 
US_ IMAGE.USE.SEGMEITATATI OI.HODE 
US_ IHAGE_USE_RECOGI ITI Ol.MODE 
US_ I MAGE_COMPUTE_RAIGE_MODE 
US_IHAGE_COMPUTE_FLOW_HODE 
US_ IHAGE_LOAD_CALIBRATI 01 
US_IMAGE_SET_P0SITI0H 
US_IMAGE_ADJUST_P0SITI0S 
US_IMAGE_ADJUST_FOCUS 
US_IHAGE_POST_SPECIFICATIOI 
US_INAGE_POST_PIXEL_HAP_READIIG 
US_IMAGE_POST_HISTOGRAM_READIIG 
US_II1AGE_P0ST_XY_CHAR_READIIG 
US_IMAGE_POST_BYTE_SYMBOLIC_READIIG 
US_IMAGE_POST_TRESHOLD_READIIG 
US_IHAGE.POST_SPATIAL_DERIVATIVE_READIIG 
US_IHAGE.P0ST_TEI1P0RAL_DEBIVATIVE_READIIG 
US_IHAGE_P0ST_REC0GIITI0I_READIIG 
US_IMAGE.POST_RAIGE_READIIG 
US_IMAGE_P0ST_FL0W_READI1G 
PROGRAMMABLE. 10 
US.PIO.EIABLE 
US.PIO.DISABLE 
US.PIO.SET.MODE 
US.PIO.COITROL.WRITE 
US.PIO.LOAD.SCALE 
US.PIO.DATA.HRITE 
US.PIO.DATA.READ 
US.PIO.BIT.READ 
US.PIO.BIT.SET 
US.PIO.TOGGLE.BIT 
OS.PIO.POST.DATA 
TASK.LEVEL.COITROL 

US.TLC.USE.JOIIT.REFEREICE.FRAME 

US.TLC.USE.CARTES I AI.REFEREICE.FRAME 

US.TLC.USE.REPRESEITATIOI.UIITS 

US.TLC.USE.ABSOLUTE.POSITIOIIIG.MODE 

US.TLC.USE.RELATIVE.POSITIOIIIG.MODE 

OS.TLC.USE.MRIST.COORDIIATE.FRAME 

US.TLC.USE.TOOL.TIP.COORDIIATE.FRAME 

OS.TLC.CHAIGE.TOOL 

US.TLC.USE.MODIFIED.TOOL.LEIGTH.OFFSETS 

US.TLC.USE.IORMAL.TOOL.LEIGTH.OFFSETS 

US.TLC.USE.IO.TOOL.LEIGTH.OFFSETS 

US.TLC.USE.KIIEMATIC.RIIG.POSITIOIIIG.MODE 

US.TLC.START.MAIUAL.MOTIOI 

US.TLC.STOP.MAIUAL.MOTIOI 

US.TLC.START.AUTOMATIC.MOTIOI 

US  _TLC_  STOP. AUTOMATI C.MOT 1 01 

US.TLC.START.TRAVERSE.MOTIOI 

US.TLC.STOP.TRAVERSE.MOTI 01 

US.TLC.START_GUARDED.MOTI 01 

US.TLC.STOP.GUARDED.MOTIOI 

US.TLC.START.COMPLIAIT.MOTIOI 

US.TLC.STOP.COMPLIAIT.MOTIOI 

US.TLC.START.FIIE.MOTIOI 

US.TLC.STOP.FIIE.MOTIOI 

US.TLC.START.MOVE.UITIL.MOTIOI 

US.TLC.STOP.MOVE.UITIL.MOTIOI 

US.TLC.START.STAIDOFF.DISTAICE 

US.TLC.STOP.STAIDOFF.DISTAICE 

US.TLC.START.FORCE.POS ITI OIIIG.MODE 

US_TLC_STOP_FORCE_POSITIOIIIG_MODE 

US.TLC.LOAD.DOF 

US.TLC.LOAD.CYCLE.TIME 

US.TLC.LOAD.REPRESEITATIOI.UIITS 


US.TLC.LOAD.LEIGTH.UIITS 

US.TLC.LOAD.REUTIVE.POSITIOIIIG 

US_TLC_ZERO_RELATIVE_POSITIOIIIG 

US.TLC.ZERO.PROGRAH.ORIGII 

US.TLC.LOAD.IIIEMATIC.RIIG.POSITIOIIIG.HODE 

US.TLC.LOAD.BASE.PARAMETERS 

US.TLC.LOAD.TOOL.PARAMETERS 

US.TLC.LOAD.OBJECT 

US.TLC.LOAD.OBJECT.BASE 

US.TLC.LOAD.OBJECT.OFFSET 

US.TLC.LOAD.DELTA 

US.TLC.LOAD.OBSTACLE.VOLUME 

US.TLC.LOAD.IEIGHBORHOOD 

US.TLC.LOAD.FEED.RATE 

US.TLC.LOAD.TRAVERSE.RATE 

US.TLC.LOAD.ACCELERATI 01 

US.TLC.LOAD.JERK 

US.TLC.LOAD.PROXIMITY 

US.TLC.LOAD.COITACT.FORCES 

US.TLC.LOAD.JOIIT.LIMIT 

US.TLC.LOAD.COITACT.FORCE.LIMIT 

US_TLC_LOAD_COITACT_TOR(}UE_LIMIT 

US.TLC.LOAD.SEISOR.FUSIOI.POS.LIMIT 

US.TLC.LOAD.SEISOR.FUSIOI.ORIEIT.LIMIT 

US.TLC.LOAD.SEGMEIT.TIME 

US.TLC.LOAD.TERMIIATIOI.COIDITIOl 

US.TLC.IICR. VELOCITY 

US.TLC.IICR.ACCELERATIOI 

US.TLC.SET.GOAL.POSITIOI 

US.TLC.GOAL.SEGMEIT 

US  _TLC_ AD JUST. AX I S 

US .TLC.UPDATE. SEISOR.FUS I 01 

US.TLC.SELECT.PLAIE 

US.TLC.USE.CUTTER.RADIUS.COMPEISATIOI 

US.TLC.START.CUTTER.RADIUS.COMPEISATIOI 

US.TLC.STOP.CUTTER.RADIUS.COMPEISATIOI 

US.TLC.STRAIGHT.TRA VERSE 

US.TLC.ARC.FEED 

US.TLC.STRAIGHT.FEED 

US_TLC_PARAMETRIC_2D_CURVE_FEED 

US_TLC_PARAMETRIC_3D_CURVE_FEED 

US.TLC.IURBS.KIOT.VECTOR 

US.TLC.IURBS.COITROL.POIIT 

US.TLC.IURBS.FEED 

US.TLC.TELEOP.FORCE.REFLECTI OI.UPDATE 
TASK.DESCRIPTIOI 

US.TDS.LOAD.USER 

US.TDS.SELECT.PROGRAM 

US.TDS.EXECUTE.PROGRAM 

US.TDS.SELECT.OPERATIOI 

US.TDS.SELECT.OPMODE 

US.TDS.LOAD.SELECTIOIS 

US.TDS.LOAD.REFEREICE.UIITS 

US.TDS.LOAD.RATE.DEFAULTS 

US.TDS.LOAD.ORIGII 

US.TDS.LOAD.SEISIIG.DEFAULTS 

TASK.KBOWLEDGE 

US.TK.DEFIIE.FRAMEHORK 
US.TK.MACRO.CREATE 
US.TK.MACRO.DELETE 
US.TI.MACRO.MODIFY 
PAREIT.TASK.PROGRAM.SEQUEICIIG 
US.PTPS.SELECT.AGEIT 
US.TPS.SELECT.TOOL 
US.PTPS.SELECT.SEISOR 
US.PTPS. IITERP.ROI.PLAI 
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US_PTPS_IITERP.HALT_PLAI 

US_PTPS_IIPUT_REgUEST 

US_PTPS_OUTPUT_EIABLE_SUBSYSTEM 

TASR.PROGRAn.SEQUEKCIIG 

US_TPS_FREESPACE_HOTIOI 
US_TPS_GUARDED_MOTI 01 
US_TPS_C0ITACT_M0TI 01 
US_TPS_SET_SUPERVISORY_MODE 
US_TPS_SELECT_FEATURE 
US_TPS_SELECT_HATERIAL 
US_L0AD_0BSTACLE 
US.LOAD.PATTERB 
US_TPS_MARK_EVEIT 
US_TPS_EIABLE 
OPERATOR. IITERFACE 

US.BEGII.FRAMEWORK 
US.EID.FRAMEWORK 
US.CREATE.FRAMEWORK 
US.DELETE.FRAMEWORK 
US.ADD.SYHBOLIC.ITEM 
US.DELETE.SYMBOLIC.ITEM 
US.ADD_SYMBOLIC_ITEM.ATTR 
US.DELETE.SYMBOLIC.ITEM.ATTR 
US.SET.SYMBOLIC.ITEM.ATTR 
OBJECT.MODELIIG 
US.OM.CREATE 
US.OM.DELETE 
US.OM.MODIFY 
OBJECT.CALIBRATIOI 
US.OC.SET.CALIB 
US.OC.GET.CALIB 
US.OC.SET.ATTR 
US.OC.GET.ATTR 
OBJECT.KIOWLEDGE 
US.OK.RECORD 
US.OK.PLAYBACK 
US.OK.CREATE.OBJ 
US.OK.DELETE.OBJ 
US.OK.MODIFY 
US.OK.MODIFY.ATTRIBUTE 
US.OK.ATTRIBUTE.QUERY 
US.OK.OOTPUT.REGISTERED.OBJ.ID 
US.OK.ATTRIBUTE.RESPOISE 
TRAJECTORY.DESCRIPTIOI 
US.TRD.OPEl 
US.TRD.ERASE 
US.TRD.RECORD 
US.TRD.RECORD.OI 
US.TRD.RECORD.OFF 
US.TRD.FIID 
US.TRD.IEXT 
US.TRD.PREVIOUS 
US.TRD.DELETE 
US.TRD.IAME.ITEM 
US.TRD.DELETE. ITEM 
US.TRD.SET.JOIIT.MODE 
US.TRD.SET.CARTESIAI.MODE 
US.TRD.MODIFY 
US.TRD.ADD.ELEMEIT 
STATUS.GRAPHICS.DISPLAY 
AIALYSIS.DIAGIOSIS.SYSTEM 

US.ADS.COLLISIOI.DETECTED 

SUBSYSTEM.SIMULATIOI 

UTAP.DATA.DEFS 

US.POST.ID 

US.GET.OBJECT.ID 


US.USE.OBJECT 

US.GET.FEATURE 

US.USE.FEATURE 

US.GET.VALUE 

US.POST.VALUE 

US.GET.LIST 

US.POST.LIST 

US.ATTRIBUTE.POST.RESPOISE 

US.ATTRI BUTE.GET.TIME 

US.ATTRIBUTE.GET.POSITIOI 

US.ATTRIBUTE.GET.ORIEITATIOI 

US.ATTRIBUTE.GET.POSE 

US.ATTRIBUTE.GET.VELOCITY 

US _ ATTR I BUTE.G ET_ ACCELERAT I 01 

US.ATTRIBUTE.GET.JERK 

US.ATTRIBUTE.GET.FORCE 

US.ATTRIBUTE.GET.TORQUE 

US.ATTRIBUTE.GET.MASS 

US.ATTRIBUTE.GET.TEMPERATURE 

US.ATTRIBUTE.GET.PRESSURE 

US.ATTRIBUTE.GET.VISCOSITY 

US.ATTRIBUTE.GET.LUMIIAICE 

US.ATTRIBUTE.GET.HUMIDITY 

US.ATTRIBUTE.GET.FLOW 

US.ATTRIBUTE.GET.HARDIESS 

US.ATTRIBUTE.GET.ROUGHIESS 

US.ATTRIBUTE.GET.GEOMETRY 

US.ATTRIBUTE.GET.TOPLOGY 

US.ATTRIBUTE.GET.SHAPE 

US.ATTRIBUTE.GET.PATTERI 

US.ATTRIBUTE.GET.MATERIAL 

US.ATTRIBUTE.GET.KIIEMATICS 
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H.2  Sorted  Interface  List 

US_2D_SEIS0R_GET_READIIG 
US_2D_SEIS0R_L0AD_ARRAY_PATTERH 
US_2D_SEIS0R_P0ST_READIIG 
US_2D_SEIS0R_USE_ARRAy_TYPE 
US .ABORT 

US.ADD.SYHBOLIC.ITEM 

US.ADD.SYMBOLIC.ITEM.ATTR 

US.ADS.COLLISIOI.DETECTED 

US.ATTRIBUTE.GET.ACCELERATIOI 

US.ATTRIBUTE.GET.FLOW 

US.ATTRIBUTE.GET.FORCE 

US.ATTRIBUTE.GET.GEOMETRY 

US.ATTRIBUTE.GET.HARDIESS 

US.ATTRIBUTE.GET.HUHIDITY 

US.ATTRIBOTE.GET.JERK 

US.ATTRIBUTE.GET.KIIEHATICS 

US.ATTRIBUTE.GET.LUHIIAICE 

US.ATTRIBUTE.GET.MASS 

US.ATTRIBUTE.GET.MATERIAL 

US.ATTRIBUTE.GET.DRIEITATIOI 

US.ATTRIBUTE.GET.PATTERI 

US.ATTRIBUTE.GET.POSE 

US.ATTRIBUTE.GET.POSITIOI 

US.ATTRIBUTE.GET.PRESSURE 

US.ATTRIBUTE.GET.ROUGHIESS 

US.ATTRIBUTE.GET.SHAPE 

US.ATTRIBUTE.GET.TEMPERATURE 

US.ATTRIBUTE.GET.TIHE 

US.ATTRIBUTE.GET.TOPLOGY 

US.ATTRIBUTE.GET.TORQUE 

US.ATTRIBUTE.GET. VELOCITY 

OS.ATTRIBOTE.GET.VISCOSITY 

US_ATTRIBUTE_POST_RESPOISE 

US.AXIS.SERVO.CLEAR.BRAKES 

US.AXIS.SERVO.HOME 

US.AXIS.SERVO.JOG 

US.AXIS.SERVO.JOG.STOP 

US.AXIS.SERVO.LOAD.CYCLE.TIHE 

US.AXIS.SERVO.LOAD.DAMPIIG.VALUES 

US.AXIS.SERVO.LOAD.DOF 

US.AXIS.SERVO.LOAD.GAII.LIHIT 

US.AXIS.SERVO.LOAD.JOIIT.LIHIT 

US.AXIS.SERVO.LOAD.PID.GAIl 

US.AXIS.SERVO.LOAD.VELOCITY.LIHIT 

US.AXIS.SERVO.SET.ACCELERATIOI 

US.AXIS.SERVO.SET.BRAKES 

US.AXIS.SERVO.SET.CURREIT 

US.AXIS.SERVO.SET.FORCES 

US.AXIS.SERVO.SET.POSITIOI 

US.AXIS.SERVO.SET.TORQUE 

US. AX I S.SERVO.SET. VELOCITY 

US.AXIS.SERVO.SET.VOLTAGE 

US.AXIS.SERVO.START.GRAVITY.COMPEISATIOI 

US.AXIS.SERVO.STOP.GRAVITY.COHPEISATIOI 

US.AXIS.SERVO.USE.ABS.POSITIOI.HODE 

US.AXIS.SERVO.USE.ABS.VELOCITY.HODE 

US.AXIS.SERVO.USE.AIGLE.UIITS 

US.AXIS.SERVO.USE.COHPLIAICE 

US.AXIS.SERVO.USE.CURREIT 

US.AXIS.SERVO.USE.FEEDFORWARD.TORQUE 

US.AXIS.SERVO.USE.IMPEDAICE 

US.AXIS.SERVO.USE.PID 

US.AXIS.SERVO.USE.RADIAI.UIITS 

US.AXIS.SERVO.USE.REL_POSITIOI.HODE 


US_AXIS_SERVO_USE_REL_VELOCITY_HODE 

US.AXIS.SERVO.USE.STIFFIESS 

US.AXIS.SERVO.USE.VOLTAGE 

US.BEGII.BLOCK 

US.BEGII.EVEIT 

US.BEGII.FRAHEWORK 

US.BEGII.HACRO 

US.BEGII.PLAI 

US.BEGII.SIIGLE.STEP 

US.CLEAR.SIIGLE.STEP 

US.CREATE.FRAMEWORK 

US.DELETE.FRAHEMORI 

US.DELETE.SYMBOLIC.ITEH 

US.DELETE.SYHBOLIC.ITEM.ATTR 

US.DISABLE 

US.EIABLE 

US.EID.BLOCK 

US.EID.EVEIT 

US.EID.FRAHEWORK 

US.EID.HACRO 

US.EID.PLAI 

US.ERROR.BAD.DATA 

US.ERROR.COMHAID.EITRY 

US.ERROR.COHMAID.IOT.IHPLEHEITED 

US.ERROR.DUPLICATE.IAME 

US.ERROR.LIMIT.EXCEEDED 

US.ERROR.IO.DATA.AVAILABLE 

US.ERROR.OVER.SPECIFIED 

US.ERROR.SAFETY.VIOLATIOI 

US.ERROR.UIDER.SPECIFIED 

US.ESTOP 

US.FLOW.LOAD.PARAHETERS 

US.FLOW.START.FLOOD 

US.FLOW.START.HIST 

US.FLOH.STOP.FLOOD 

US.FLOW.STOP.HIST 

US.FT.SEISOR.POST.READIIG 

US_GEIERIC_STATUS_REPORT 

US.GET.EXT.DATA. VALUE 

US.GET.FEATURE 

US.GET.LIST 

US.GET.OBJECT.ID 

US.GET.SELECTIOI.ID 

US.GET.VALUE 

US.HALT 

US.HOLD 

US.IHAGE.ADJUST.FOCUS 

US.IHAGE.ADJUST.POSITIOI 

US.IHAGE.COHPUTE.FLOW.HODE 

US.IHAGE.COHPUTE.RAIGE.HODE 

US.IHAGE.COHPUTE.SPATIAL.DERIVATIVES.HODE 

US.IHAGE.COHPUTE.TEHPORAL.DERIVATIVES.HODE 

US.IHAGE.LOAD.CALIBRATIOI 

US.IHAGE.POST.BYTE.SYMBOLIC.READIIG 

US.IHAGE.POST.FLOW.READIIG 

US.IHAGE.POST.HISTOGRAM.READIIG 

US.IHAGE.POST.PIXEL.MAP.READIIG 

US.IMAGE.POST.RAIGE.READIIG 

US.IHAGE.POST.RECOGIITIOI.READIIG 

US.IHAGE.POST.SPATIAL.DERIVATIVE.READIIG 

US. IHAGE.POST.SPECIFICATI 01 

US.IMAGE.POST.TEMPORAL.DERIVATIVE.READIIG 

US.IHAGE.POST.TRESHOLD.READIIG 

US. IHAGE.POST.XY.CHAR.READIIG 

US.IHAGE.SET.POSITIOI 

US. IHAGE.USE.CEITRO ID.HODE 
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US_ IMAGE.USE.FRAME.GRAB.HODE 

US_IHAGE_USE_GRAY_LEVEL_MODE 

US_IMAGE_USE.HIST0GRAF1_M0DE 

US_IMAGE_USE_RECOGIITIOB_MODE 

US_IMAGE_USE_SEGHEITATATIOI_MODE 

US_IMAGE_USE_TRESHOLD_MODE 

US.IIIT 

US.LOAD.EXT.PARAMETER 

US.LOAD.OBSTACLE 

US.LOAD.PATTERI 

US.LOAD.STATUS.PERIOD 

US_LOAD_STATUS_TYPE 

US.MARK.BREAKPOIIT 

US.MARK.EVEIT 

US_IEXT_SIIGLE_STEP 

US_OC_GET_ATTR 

US_OC_GET_CALIB 

US_OC_SET_ATTR 

US_OC_SET_CALIB 

US.OK.ATTRIBUTE.QUERY 

US_OK_ATTRIBUTE_RESPOISE 

US_OK_CREATE_OBJ 

US_OK_DELETE_OBJ 

US_OK_llODIFY 

US_OK_NODIFY_ATTRIBUTE 

US_OK_OUTPUT_REGISTERED_OBJ_ID 

US_OK_PLAYBACK 

US_OK_RECORD 

US_OM_CREATE 

US_OM_DELETE 

US_OH_MO0IFY 

US.PAUSE 

US_PIO_BIT_READ 

US_PIO_BIT_SET 

US.PIO.COITROL.HRITE 

US_PIO_DATA.READ 

US_PIO_DATA_HRITE 

US_PIO_DISABLE 

US.PIO.EIABLE 

US_PIO_LOAD_SCALE 

US_PI0_P0ST_DATA 

US_PIO_SET_HODE 

US.PIO.TOGGLE.BIT 

US_PQST_EXT_DATA_ VALUE 

US_POST_ID 

US_POST_LIST 

US_POST_SELECTIOI_ID 

US_POST_VALUE 

OS_PTPS_IIPUT_REQUEST 

US_PTPS_IITERP_HALT_PLAI 

US_PTPS_IITERP_RUI_PUI 

US_PTPS_0UTPUT_E1ABLE_SUBSYSTEM 

US_PTPS_SELECT_AGEIT 

US.PTPS.SELECT.SEISOR 

US.RESET 

US.RESUME 

US_SCALAR_SEISOR.POST_READIIG 

US_SEISOR_GET_ATTRIBUTES_READIIG 

US_SEISOR_GET_READIIG 

US_SEISOR_LOAD_FILTER 

US_SEISOR_LOAD_FREQUEICY 

US_SEISOR_LOAD_SAMPLIIG_SPEED 

OS_SE1SOR_LOAD_TRAISFORM 

US_SEIS0R_USE_HEASUREMEIT_U1ITS 

US_SET_EXT_DATA_VALUE 

US_SET_SYHBOLIC_ITEH_ATTR 


US.SHUTDOWI 

US_SPIIDLE_LOAD_SPEED 

US_SPIIDLE_LOCK_Z 

US.SPIIDLE.ORIEIT 

US.SPIIDLE.RETRACT 

US_SPIIDLE_RETRACT_TRAVERSE 

US.SPIIDLE.START.TURIIIG 

US_SPIIDLE_STOP_TURIIIG 

US_SPIIDLE_USE_FORCE 

US_SPIBDLE_USE_IO_FORCE 

US.START 

US .STARTUP 

US.START.FILTER 

US.START.TRABSFORH 

US.STOP 

US.STOP.FILTER 

US.STOP.TRABSFORH 

US.TDS.EXECUTE.PROGRAH 

US.TDS.LOAD.ORIGIB 

US.TDS.LOAD.RATE.DEFAULTS 

US.TDS.LOAD.REFEREBCE.UBITS 

US.TDS.LOAD.SELECTIOBS 

US.TDS.LOAD.SEBSIBG.DEFAULTS 

US.TDS.LOAD.USER 

US.TDS.SELECT.OPERATIOB 

US.TDS.SELECT.OPHODE 

US.TDS.SELECT.PROGRAM 

US.TK.DEFIBE.FRAHEWORK 

US.TK.MACRO.CREATE 

US.TK.MACRO.DELETE 

US.TK.MACRO.MODIFY 

US.TLC.ADJUST.AXIS 

US.TLC.ARC.FEED 

US.TLC.CMABGE.TOOL 

US.TLC.GOAL.SEGMEBT 

US  _TLC_ I BCR. ACCELERATI OB 

US.TLC.IBCR. VELOCITY 

US.TLC.LOAD.ACCELERATIOB 

US.TLC.LOAD.BASE.PARAMETERS 

US.TLC.LOAD.COBTACT.FORCES 

US.TLC.LOAD.COBTACT.FORCE.LIHIT 

US.TLC.LOAD.COBTACT.TORqUE.LIHIT 

US.TLC.LOAD.CYCLE.TIHE 

US.TLC.LOAD.DELTA 

US_TLC.LOAD.DOF 

US_TLC.LOAD_FEED.RATE 

US.TLC.LOAD.JERX 

US.TLC.LOAD.JOIBT.LIMIT 

US.TLC.LOAD.KIBEMATIC.RIBG.POSITIOBIBG.NODE 

US.TLC.LOAD.LEBGTH.UBITS 

US.TLC.LOAD.BEIGHBORHOOD 

US.TLC.LOAD.OBJECT 

US.TLC.LOAD.OBJECT.BASE 

US.TLC.LOAD.OBJECT.OFFSET 

US.TLC.LOAD.OBSTACLE.VOLUME 

US.TLC.LOAD.PROXIMITY 

US.TLC.LOAD.REUTIVE.POSITIOBIBG 

US.TLC.LOAD.REPRESEBTATIOB.UBITS 

US.TLC.LOAD.SEGMEBT.TIHE 

US.TLC.LOAD.SEBSOR.FUSIOB.ORIEBT.LIMIT 

US.TLC.LOAD.SEBSOR.FUSIOB.POS.LIHIT 

US.TLC.LOAD.TERMIBATIOB.COBDITIOB 

US.TLC.LOAD.TOOL.PARAMETERS 

US.TLC.LOAD.TRAVERSE.RATE 

US.TLC.BURBS.COBTROL.POIBT 

US.TLC.BURBS.FEED 
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US_TLC_IU11BS_KI0T_VECT0R 

US_TLC_PARAMETRIC_2D_CURVE_FEED 

US_TLC_PARANETRIC_3D_CURVE_FEED 

US_TLC_SELECT_PUIE 

US_TLC_SET_GOAL_POSITIOI 

US_TLC_START_AUTOKATIC_HOTIOI 

US_TLC_START_COHPLIAIT_MOTIOI 

US_TLC_START_CUTTER_RADIUS_COHPaSATIOI 

US_TLC_START_FIIE_I10TI0I 

US_TLC_START_FORCE_POSITIOIIIG_HODE 

US_TLC_START_GUARDED_MOTIOI 

US_TLC_START_MAIUAL_I10TI0I 

US_TLC_START_HOVE_UITIL_MOTIOI 

US_TLC_START_STAIDOFF_DISTAICE 

US_TLC_START_TRAVERSE_MOTIOI 

US_TLC_STOP_AUTOMATIC_MOTIOI 

US_TLC_ST0P_C0MPLIAIT_M0TI01 

US_TLC_STOP_CUTTER_RADIUS_COI1PEISATIOI 

US_TLC_ST0P_FIIE_(10TI0I 

US_TLC.STOP_FORCE_POSITIOIIIG_IIODE 

US_TLC.STOP_GUARDED_HOTIOI 

US_TLC_STOP_MAIUAL_MOTIOI 

US.TLC.STOP.NOVE.UITIL.HOTIOI 

US_TLC_STOP_STAIDOFF.DISTAICE 

US_TLC_ST0P_TRAVERSE_M0TI01 

US _TLC_STRA I GHT.FEED 

US_TLC_STRAIGHT.TRAVERSE 

US_TLC_TELEOP_FORCE_REFLECTI OI.UPDATE 

US_TLC_UPDATE_SEIS0R_FUSI01 

US_TLC_USE_ABSOLUTE_POSITIOIIIG_HODE 

US.TLC_USE_CARTESIAI_REFEREICE_FRAHE 

US_TLC_USE_CUTTER_RADIUS_C0I1PEISATI01 

US_TLC_USE_JOIIT_REFEREICE_FRAME 

US_TLC_USE_KIIEMATIC_RIIG_POSITIOIIIG_HODE 

US_TLC_USE_MODIFIED_TOOL_LEIGTH_OFFSETS 

US_TLC_USE_I0RMAL_T00L_LE1GTH_0FFSETS 

US_TLC_USE_IO_TOOL_LEIGTH_OFFSETS 

US_TLC_USE_RELATIVE_P0SITI01IIG_I10DE 

OS_TLC_USE_REPRESEITATIOI_U1ITS 

US_TLC_OSE_TOOL_TIP_COORDIIATE_FRAIIE 

US_TLC_USE_HRIST_COORDIIATE_FRAHE 

US_TLC_ZER0_PR0GRA11_0RIGII 

US_TLC_ZERO_RELATIVE_POSITIOIIIG 

US_TPS_C0ITACT_H0TI0I 

US_TPS_EIABLE 

US_TPS_FREESPACE_HOTIOI 

US_TPS_GUARDED_MOTIOI 

US_TPS_HARK_EVEIT 

US.TPS _ SELECT.FEATURE 

US _TPS_ SELECT. HATERI AL 

US.TPS.SELECT.TOOL 

US.TPS.SET.SUPERVISDRY.HODE 

US.TRD.ADD.ELEHEIT 

US.TRD.DELETE 

US.TRD.DELETE.ITEM 

US.TRD.ERASE 

US.TRD.FIID 

US.TRD.HODIFY 

US.TRD.IAHE.ITEM 

US.TRD.IEXT 

US.TRD.OPEI 

US.TRD.PREVIOUS 

US.TRD.RECORD 

US.TRD.RECORD.OFF 

US.TRD.RECORD.OI 

US.TRD.SET.CARTESIAI.HODE 


US.TRD.SET.JOirr.HODE 

US.USE.AXIS.HASK 

US.USE.EXT.ALGORITHH 

US.USE.FEATURE 

US.USE.MACRO 

US.USE.OBJECT 

US.USE.PLAI 

US.USE.SELECTIOI 

US.VECTOR.SEISOR.GET.READIIG 

US.VECTOR.SEISOR.POST.READIIG 

US .ZERO 
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H.3  Interface  Source  Listings 
H.3.1  Disclaimer 

//=================  utap.disclaimer.h  ================:====== 

// 

// 

//  Unified  Telerobotic  Architecture  Project  (UTAP) 

II  Interface  Definitions 
//  Release:  1.0 
//  Revision  0.0 
//  Release  Date:  24-May-1994 
// 

// 

tdefine  UTAP.VERSIOI  1.0 

// 

//  DISCLAIMER: 

// 

//  This  softsare  eas  produced  by  the  lational  Institute  of  St2aidards  and 
//  Technology  (IIST) , an  agency  of  the  U.S.  government,  and  by  statute  is 
//  not  subject  to  copyright  in  the  United  States.  Recipients  of  this 
//  softsare  assume  all  responsibility  associated  with  its  operation, 

//  modification,  maintenance,  and  subsequent  redistribution. 

// 

// 


/• 

Modification  History: 

06/18/94  jlm  Public  Release  of  Messages 

05/23/94  jlm  Modified  definitions  for  greater  consistency. 
04/24/94  jlm  Created 

•/ 


H.3. 2 Generic  Definitions 

//==========  generic_types  .h  =~~~~=~==~=~ ==  ~ 

// 

//  FILE  : generic_types .h 

// 

//  PURPOSE  : This  file  contains  a list  of  domain-independent  types 

// 

//  DATE  : lovemeber  17,  1993 

// 

// 

tifndef  UTAP.GEIERIC.DEFIIITIOIS 
•define  UTAP.GEIERIC.DEFIIITIOIS 


// 

//  MODE. DIRECTIVES  - class  to  define  enumerated  set  of  process  modes 
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// 

class  NODE.DIRECTIVE  { 
enuffl  { 


abort 

= 

0x10001 

halt 

= 

0x10002 

pause 

= 

0x10004 

resume 

= 

0x10008 

reset 

= 

0x10011 

estop 

= 

0x10012 

report 

= 

0x10014 

start 

= 

0x10018 

shutdown 

= 

0x10020 

hold 

= 

0x10021 

reinitialize 

= 

0x10022 

} : 


// 

//  GE1ERIC_DIRECTIVES  - class  of  enumerated  set  of 

// 

class  GEIERIC.DIRECTIVES  : public  HODE.DIRECTIVE  { 


enum 

{ 

no.change  = 0x0000, 

no.selection  = 0x0001, 

delegate.selection  = 0x0002, 

no_op  = 0x0004 

} : 

}; 


//  use  same  parameter 

//  parameter  not  required 

//  let  subordinate  decide  parameter 

//  slot  for  commandless  mode  directive 


// 

//  LOGICAL  TYPE  - enumerated  list  of  logical  states 

// 

typedef  enum  { 
tif  ! defined (TRUE) 

TRUE  = 1, 

tendif 

•if  *defined(FALSE) 

FALSE  = 0 , 

tendif 

ALL  = -1 , //  good  for  bitmask 

} LOGICAL; 

// 

//  USER.TYPE 

// 

typedef  enum  USER_TYPE  { 


ATTEIDAIT 

= 

1 

OPERATOR 

= 

2 

PROGRAMMER 

= 

3 

MAIAGER 

= 

4 

MAIITEIAICE 

= 

5 

SYSTEMS 

= 

6 

ROOT 

= 

8 

} USER.TYPE; 


// 

//  HODE.STATE 

// 

typedef  enum  { 
calibration 
diagnostic 
maintenance 
normal.operation 
safe 

shutdown 


= 0x40001, 
= 0x40002, 
= 0x40004, 
= 0x40008, 
= 0x40010, 
= 0x40012, 
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initialize 

training 

teleoperation 

shared 

} 


= 0x40014, 
= 0x40018, 
= 0x40020, 
= 0x40020 


MODE.STATE; 


// 


//  RESULT.TYPE  - 
// 

typedef  enum  { 

enumerated 

set  of  result  possibilities 

failed 

= -1, 

incomplete 

= 0, 

succeeded 

= 1 , 

partial.sucess 

= 2 

//  exception 

= -2, 

//  exception  is 

different 

kind  of  failure 

} RESULT.TYPE ; 

// 

//  STATE_TYPE  - enumerated  set  of 

// 

typedef  enum  { 
finished , 
ready , 
halted , 
suspended , 
aborted, 
resetting , 
exception , 
executing 

/*  executing.forveu'd , /*  future  •/ 

/♦  executing.backward,  /•  future  •/ 

} 

// 

//  STATUS.TYPE  - synonym  of  STATE.TYPE 

// 

typedef  STATE.TYPE  STATUS.TYPE; 

// 

//  REQUEST.TYPE  - enumerate  set  of  request  states 

// 

typedef  enum  { 

request.started , 
request .pend ing , 
request.complete , 
request. blocked , 
request.f ailed , 
request. aborted 

} REQUEST.TYPE; 


//or  is  done  better  ? , see  result. type 


//  same  as  running 


STATE.TYPE ; 


// 

//  TIME  - get  POSIX  definition 

// 

typedef  double  TINE; 

// 


//  TINELIIE  - struct 

definition  of  time  fr^une 

// 

struct  TINELIIE  { 

TINE 

duration ; 

// 

how  long  to 

take 

TINE 

earliest. start ; 

// 

earliest  to 

start 

TINE 

latest. start ; 

// 

latest  to  start 

TINE 

earliest. completion ; 

// 

earliest  to 

finish 
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TIME 


latest.completion ; //  latest  to  finish 


}; 

// 

//  SEVERITY.TYPE  - enumerated  definition  of  severity  types 

// 

typedef  enum  { 
fatal , 
severe , 
sarning, 
informative 

} SEVERITY.TYPE; 


// 

//  POSITIOSIIG_TYPE  - enumerated  definition  of  positioning  types 

// 

typedef  enum  { 
absolute , 
incremental , 

jog. 

relative , 

} POSITIOIIIG.TYPE; 


•endif 


H.3.3  Classification 

//=================  utap_classification.h  ===============: 

//  NODULES  ACROIYHS: 

// 

// 

//  TDS  - task  description  and  supervision 
//  TPS  - task  program  sequencer 
//  TPS  - parent  program  sequencer 
//  TLC  - task  level  control 

//  DC  - device  control 

// 

//  01  - operator  interface 

//  OX  - object  knowledge 

//  TK  - task  knowledge 

//  TD  - trajectory  description 

//  SGD  - status  graphics  displays 
//  SS  - subsystem  simulators 

//  AD  - analysis  and  diagnosis 

//  VS  - virtual  sensor 

//  DB  - data  base 

//  SC  - sensor  control 

//  AC  - axis  servo  control 

// 

//  UTAP  Classification  Typing 

// 

tifndef  UTAP.CLASSIFICATIOI 
•define  UTAP.CLASSIFICATIOI 

enum  { .JOYSTICK, 

_F_R_ JOYSTICK, 

.PEIDAIT , 

.PAIEL, 

.WIIDOWS , 
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} 

eniim  { .TEACH  = 0x01 , 

.SCRIPTED  = 0x02, 
.PROGRAHHABLE  = 0x04 , 

} 

enum  { .MAIIPULATIOI  = 0x01 , 
.lAVIGATIOB  = 0x02, 
.TOOLIIG  = 0x04, 

.HACHIIIIG  = 0x08, 

//  obviously  more 

} 

enum  { .PICK. PLACE  = 0x01 , 
.DEXTROUS  = 0x02, 

//??? 

} 

enum  { .TELEOP  = 0x01 , 

.GUIDED  = 0x02, 

.AUTOIOMOUS  = 0x04 , 

/ /??? 

} 

enum  { .VERTICAL  = 0x01 , 
.HORIZOITAL  = 0x02, 
.TURIIIG  = 0x04, 

.EDM  = 0x08 , 

/ /??? 

} 

enum  { .COITACT  = 0x01 , 

.lOICOITACT  = 0x02 , 

} 

0x01, 
0x02, 
0x03, 
0x04, 


enum  { .DEIAVIT.HARTEIBURG  = 
.SCARA 
.GAITRY 

.STEHART.PLATFORM  = 
//  obviously  more 


US.OI.MODULE.TYPES ; 


US.TD.HODULE.TYPES ; 


US.TPS.HODULE.TYPES ; 


US.TPS.HAIIPULATIOI.TYPES ; 


US.TPS.lAVIGATIOl.TYPES ; 


US.TPS.MACHIIIIG.TYPES ; 


US.TPS.TOOLIIG.TYPES ; 


US.ROBOT.TYPES; 


enujD 

{ 

.SPRAY 

= 0x01, 

.FIIISH 

= 0x02, 

} 

US.TOOL.TYPES : 

enum 

.FTS 

= 0x1 , 

.IMAGE 

= 0x2, 

.PROBE 

= 0x3, 

.SWITCH 

= 0x4, 

.RAIGE 

= 0x5, 

} US.SEISOR.TYPES ; 


Bendif 


H.3.4  Protocol 
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// 

//  UTAP  Protocol  Typing 

// 


struct  NsgTransmitHeader  { 

int  byte_order;  //  big/little  endian? 

int  command.num;  //  increment  with  every  nee  command 

//  any  others?? 

}; 

struct  NsgAckHeader  { 

int  byte.order; 
int  echo.message.num; 
int  health ; 

//  any  others?? 


MDDE.DIRECTIVE  mode;  //  combine  mode  x command 


//  big/little  endiain? 

//  acknosledge  receipt 

//  health  of  device  - mimics  Lords  Sensor 


typedef  enum  { 
read.only , 
write.only , 
read_urite 

} ACCESS.TYPE ; 

typedef  int  CHAIIEL ; 


typedef  enum  { 

SEID, 

RECEIVE 

} COHHUIICATIOI.DIRECTIOI.TYPE; 


typedef  enum  { local_procedure_call , 
remote_procedure_call , 
sv.interrupt , 
event , 
signal , 

HNS, 

netsork.comm, 
shared.memory , 
message.queue , 
mailbox , 

SP_60 , 

SERCOS , 

CAl, 

} COIIECTIOI.TYPE; 


H.3.5  Information  Model 

/ / ========= •— =—  utap_data_defs  .h  == 

•ifndef  UTAP_DATA_DEFS 
tdefine  UTAP.DATA.DEFS 
tinclude  “generic.defs.h" 

typedef 

enum  { X.AXIS  = 0x01, 

Y.AXIS  = 0x02, 
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Z.AXIS  = 0x04, 

POSITIOI.AXES  = 0x07, 


ROLL.AXIS 

PITCH.AXIS 

YAW.AXIS 

ORIEITATIOl.AXES  = 


0x08, 

0x10, 

0x20, 

0x38, 


JOIITl.AXIS 

J0IIT2_AXIS 

J0IIT3_AXIS 

J0IIT4_AXIS 

J0IIT5_AXIS 

J0I1T6_AXIS 

J0IIT7_AXIS 

J0IIT8_AXIS 

J0IIT9_AXIS 

JOIITIO.AXIS 


0x01, 
0x02, 
0x04, 
0x08, 
0x10, 
0x20, 
0x40, 
0x80, 
0x100, 
0x200 , 


//  Modifiers 
ELBOW 
WRIST 
TOOLTIP 


0x1000, 
0x2000 , 
0x4000 , 


} AxisNask; 


typedef 

enum  { unitless.u 
moters.u 
grams.u 
litors.u 
seconds.u 
radians.u 
angles.u 
nestons_u 
celsius.u 
pascal.u 
lumin.u 
psi_u 
rpm_u 
Hz_u 

cardinal.u 

updown.u 


0x00, 

(1L«1) , 
(1L«2)  , 
(1L«3)  , 
(1L«4)  , 
(1L«5)  , 
(1L«6)  , 
(1L«7)  , 
(1L«8)  , 
(1L«9)  , 
(1L«10)  , 
(1L«11)  , 
(1L«12)  , 
(1L«13)  , 
(1L«14)  , 
(OxlL  « 33), 


//  lon-SI  Modifier 


nano.u  = 

micro.u  = 

milli_u  = 

kilo.u  = 

nonSI.Bodif ier  = 


(1L«20) , 
(1L«21) , 
(1L«22) , 
(1L«23)  , 
(OxFL  « 20) , 


//  lon-SI  altogether 


inches.u  = 

feet_u  = 

pounds.u  = 

English.units  = 


(1L«30) , 
(1L«31) , 
(1L«32)  , 
(OxFL  « 30), 


} Measurement_unit8_type ; 


typedef 

enuin  { 

char_t 

short.t 


0x0100001 , 
0x0100002 , 
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int_t 

= 

0x0100003, 

long_t 

= 

0x0100004 , 

u_char_t 

= 

0x0100005 , 

u_8hort_t 

= 

0x0100006, 

u_int_t 

= 

0x0100007 , 

u_long_t 

= 

0x0100008 , 

float.t 

= 

0x0100009, 

double.t 

= 

OxOlOOOOA , 

array_t 

= 

0x0200000 , 

ptr_t 

= 

0x0400000 , 

cartesian_t 

S 

0x1000000, 

spherical_t 

= 

0x2000000 , 

cylindrical_t 

= 

0x3000000, 

H_niatrice_t 

= 

0x4000000 , 

// 

naop  homogeneous  transform  matrix 

transfonn_t 

= 

0x4000000 , 

// 

ibid 

Euler_t 

= 

0x5000000 , 

// 

Euler  Angles 

ZYXEuler.t 

= 

0x5000000 , 

// 

ZYX  Euler  Angles 

ZYZEuler.t 

= 

0x6000000 , 

// 

ZYZ  Euler  Angles 

Quaternion_t 

= 

0x7000000 , 

// 

Quaternian  Angles 

Equiv_Angle_Axis_t 

= 

0x8000000 , 

// 

Equivalent  Angle  Axis 

RPY.t 

0x9000000 , 

// 

Roll  Pitch  Yaw 

geometry.t 

= 

0x10000000, 

topology_t 

= 

0x20000000, 

material.t 

= 

0x30000000, 

shape.t 

0x40000000, 

pattern_t 

= 

0x50000000, 

kinematics.t 

= 

0x60000000, 

bitmask.t 

s 

0x100000000, 

} Hepresentation.units.type ; 

// 

//  Object  type 

// 

struct  Object_type  { 
int  id; 


.location. 

= 

0x80000 

.part. 

= 

0x80001 

.simple. 

= 

0x80002 

.robot. 

s 

0x80003 

.tool. 

= 

0x80004 

.list. 

= 

0x80005 

.module. 

= 

0x80006 

} type; 

}; 

// 

//  Attribute  Types  - Enuneration 

// 

typedef  enuin  { 


.object.name. 

= 

0x0000001 

.attribute.name. 

= 

0x0000002 

.material.name. 

= 

0x0000004 

.time. 

= 

0x0000008 

.position. 

= 

0x0000040 

.orientation. 

= 

0x0000080 

.pose. 

= 

0x0000100 

.velocity. 

= 

0x0000200 

.acceleration. 

= 

0x0000400 

-jerk. 

= 

0x0000800 

.force. 

= 

0x0001000 

.torque. 

= 

0x0002000 

.temperature. 

= 

0x0004000 
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.pressure. 

.viscosity. 

.luminemce. 

.humidity. 

.flow. 

.hardness. 

.roughness. 

.mass. 

.geometry. 

.topology. 

.shape. 

.pattern. 

.material. 

.kinematics. 


0x0008000 , 
0x0010000, 
0x0020000 , 
0x0040000 , 
0x0080000 , 
0x0100000, 
0x0200000 , 
0x0400000 , 

0x01000000, 
0x02000000 , 
0x04000000 , 
0x08000000 , 
0x10000000, 
0x20000000 , 


= 0x100000000, 
= 0x200000000, 
= 0x400000000, 
= 0x800000000, 
= 0x1000000000 


//  Bhere  does  this  info  belong? 
.link. length. 

.link. twist. 

.link. offset. 

.link.mass. 
.link.encoder.ticks. 


#if  0 

//  lot  supported  from  hereon  in 
.elasticity, 
.spring.constant. , 
.illumination. , 

.pitch. , 

.loudness., 

.intensity. , 

.amplitude. , 

.frequency 
.count. , 

.period. , 

.phase. , 

•endif 

} Attribute. t; 

// 

//  State  Modifier  of  Attribute 

// 

typedef  enum  { 

all  = -1, 

translational  = 0x00001, 
rotational  = 0x00002, 


//  sensing  modifiers  - more  get  oriented 

actual  = 0x00100, 

desired  = 0x00200, 

meuc  = 0x00400 , 

min  = 0x00800 , 

last  = 0x01000, 


// 

// 

// 

// 


positiong  modifier  - more  set  oriented 


absolute 

relative 

incremented 


//  jog 

} Hodifier.t; 


= 0x02000, 
= 0x04000, 
= 0x08000, 
= 0x10000, 


// 

//  Generic  Attribute  Data  Storage 

// 

tinclude  <sys/types .h> 
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struct  gonoric_value_a  { 
public : 
union  { 


char 

c ; 

short 

s ; 

int 

i ; 

long 

1; 

u.char 

uc ; 

u. short 

us ; 

u.int 

ui ; 

u.long 

ul; 

float 

f ; 

double 

d; 

void  * 

heap ; 

} value,  min,  max; 


//  variable  data  folios  in  heap  format 


or  get  query  routing  destination 

//  post  response  to  questioner 
//  posting  response  values  to  cental  obj  knosl 
//  get  next  values  from  obj  knosl 
//  use  data  as  delta  offset 
//  to  alter  cmd  dx,dy ,dz,rx,ry ,rz 
//  Bitmask  to  indicate  destination  for  response 
//  0 means  continuous,  1=  one  read,... 

//  frequency  of  update 
//  optional  delta  offset  position 

// 

//  General  Purpose 

// 

•define  US.POST.ID  60 
struct  us_post_id_msg_t  { 
int  msgid; 
int  id; 

}; 

•define  US_GET_OBJECT_ID  51 
struct  us_get_object_id_msg_t  { 
int  msgid ; 
char  name [128] ; 

}; 


// 

//  ROUTE  - struct  to  define  read 
// 

struct  ROUTE  { 

enum  { .STATUS  = 1 , 

_IIRITE_T0_0K  = 2, 
_READ_FR0M_0K  = 4 , 
_DELTA_OFFSET  = 8 , 
.ALTER  = 8 , 

} type; 
int  times; 

TIRE  update.period; 
int  offset ; 

}; 


•define  US.USE.OBJECT  52 

struct  us. use. object msg.t  { 

int  msgid; 
int  id; 

}; 


•define  US.GET.FEATURE  63 

struct  us.get.feature msg.t  { 

int  msgid; 
char  name [128] ; 

ROUTE  r; 

}; 


•define  US.USE.FEATURE  64 
struct  us.use.feature.msg.t  { 
int  msgid; 
int  id ; 
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#define  US.GET.VALUE  55 
struct  U8_get_value_msg_t  { 
int  nsgid; 

ROUTE  r; 

Attribute.t  items; 
Modifier_t  modifiers; 


•define  US_POST_VALUE  56 
struct  us_post_value_msg_t  { 
int  msgid ; 
int  id; 

Attribute.t  item; 

Hodifier.t  modifier; 
Representation.units.type  rep; 
Measurement.units.type  units ; 
generic.value.a  value; 

}; 


•define  US.GET.LIST  57 
struct  us_get_list_msg_t  { 
int  msgid; 

ROUTE  r; 

Attribute.t  items; 
Modifier. t modifiers; 

}; 


•define  US.POST.LIST  58 
struct  us.post.list.msg.t  { 
int  msgid; 

Attribute.t  items; 
Nodifier.t  modifiers; 
generic. value.a  *values ; 


// 

// 

//  Object  Knosledge  Specific  Attribute  Messages 

// 

// 

•define  US.ATTRIBUTE.POST.RESPOISE  1600 
struct  us.attribute.post.response.msg.t  { 
int  msgid ; 
int  id ; 

Attribute.t  item; 

Modifier.t  modifier; 
int  size; 

Representation.units.type  rep; 

Measurement .units.type  units; 
generic.value.a  value; 


•define  US.ATTRIBUTE.GET.TIME  1601 
struct  us.attribute.get.time.msg.t  { 
int  msgid; 
int  id; 

ROUTE  r; 

Modifier.t  modifier; 

Measurement.units.type  desired.units ; 

}; 


•define  US.ATTRIBUTE.GET.POSITIOl  1602 
struct  us.attribute.get.position.msg.t  { 
int  msgid ; 
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int  id; 

ROUTE  r; 

(lodifier_t  modifier; 

Representation_units_type  rep  = double_t ; 
Neasurement_units_type  units  = meters.u; 


tdefine  US_ATTRIBUTE_GET_ORIEHTATIOI  1603 
struct  us_attribute_get_orientation_msg_t  { 
int  msgid; 
int  id; 

ROUTE  r; 

Hodifier_t  modifier; 

Heasurement_units_type  desired.units  = radians.u; 

}; 


tdefine  US_ATTRIBUTE_GET_POSE  1604 
struct  us_attribute_get_pose_msg_t  { 
int  msgid; 
int  id; 

ROUTE  r; 

Ilodifier_t  modifier; 

Measurement_units_type  desired_pos_units ; 
Measurement_units_type  desired_rot_units ; 

}; 


tdefine  US_ATTRIBUTE_GET_VELOCITY  1605 
struct  us_attribute_get_velocity_msg_t  { 
int  msgid; 
int  id ; 

ROUTE  r; 

Hodifier_t  modifier; 

Measurement _units_type  desired.units  = meters.u; 

}; 


tdefine  US_ATTRIBUTE_GET_ACCELERATIOI  1606 
struct  us_attribute_get_acceleration_msg_t  ■{ 
int  msgid ; 
int  id; 

ROUTE  r; 

Hodifier.t  modifier; 
enum  { time_to_accel_u, 

meters_per_sec_per_sec 
} desired.units  = meters_per_sec_per_sec  ; 

}; 

tdefine  US_ATTRIBUTE_GET_JERK  1607 
struct  us_attribute_get_ jerk_msg_t  { 
int  msgid ; 
int  id; 

Modifier_t  modifier; 

enum  { meters_per_sec_per_8ec  } units; 

}; 


tdefine  US_ATTRIBUTE_GET_FORCE  1608 
struct  us_nttribute_get_force_msg_t  { 
int  msgid; 
int  id; 

ROUTE  r; 

Modifier_t  modifier; 

Neasurement_units_type  desired.units  = nestons.u; 

}; 


tdefine  US_ATTRIBUTE_GET_TORQUE  1609 
struct  us_attribute_get_torque_msg_t  { 
int  msgid ; 
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int  id; 

ROUTE  r; 

Hodifier_t  modifier; 

enum  { neBtons_per_meter  } desired.units ; 


♦define  US_ATTRIBUTE_GET_MASS  1610 
struct  U8_attribute_get_mass_msg_t  { 
int  msgid; 
int  id; 

ROUTE  r; 

Modifier_t  modifier; 
int  size; 

Heasurement_units_type  desired_units  = grams.u; 

}; 


♦define  US_ATTRIBUTE_GET_TEMPERATURE  1611 
struct  us_attribute_get_temperature_msg_t  { 
int  msgid; 
int  id; 

ROUTE  r; 

Modifier.t  modifier; 

Neasurement_unit8_type  desired.units  = celsius_u; 

}; 


♦define  US_ATTRIBUTE_GET_PRESSURE  1612 
struct  us_attribute_get_pre8sure_msg_t  { 
int  msgid ; 
int  id; 

Nodifier.t  modifier; 

Neasurement_unit8_type  desired.units  = pascal.u; 

}; 


♦define  US_ATTRIBUTE_GET_VISCOSITY  1613 
struct  us_attribute_get_vi8cosity_m8g_t  { 
int  msgid; 
int  id; 

ROUTE  r; 

Modifier_t  modifier; 

enum  { mPa.per.second}  desired.units ; 

}; 


♦define  US.ATTRIBUTE.GET.LUHIIAICE  1614 
struct  us_attribute_get_luminance_m8g_t  { 
int  msgid ; 
int  id; 

ROUTE  r; 

Modifier_t  modifier; 

Neasurement_units_type  desired.units  = lumin.u; 

}; 


♦define  US_ATTRIBUTE_GET_HUI1IDITY  1615 
struct  u8_attribute_get_humidity_msg_t  { 
int  msgid; 
int  id; 

ROUTE  r; 

Nodifier.t  modifier; 

enum  {grams_per_meter,cubed  } desired.units ; 

}; 


♦define  US_ATTRIBUTE_GET_FLOU  1616 
struct  us_attribute_get_flow_m8g_t  { 
int  msgid; 
int  id; 

ROUTE  r; 
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Nodifier.t  modifier; 

Neasurement_units_type  desired.units ; 


fdefine  US_ATTRIBUTE_GET_HARDIESS  1617 
struct  us_attribute_get_hardness_msg_t  { 
int  msgid; 
int  id; 

ROUTE  r; 

Modifier_t  modifier; 

Heasurement_units_type  desired_units ; 

}; 


#define  US_ATTRIBUTE_GET_ROUGHIESS  1618 
struct  us_attribute_get_roughness_msg_t  { 
int  msgid; 

ROUTE  r; 

Modifier_t  modifier; 
Measurement_units_type  desired_units ; 


tdefine  US.ATTRIBUTE.GET.GEOMETRY  1619 
struct  us_attribute_get_geometry_msg_t  { 
int  msgid; 
int  id ; 

ROUTE  r; 

Modifier.t  modifier; 
Heasurement.units.type  desired_units ; 

}; 


tdefine  US.ATTRIBUTE.GET.TOPLOGY  1620 
struct  us_attribute_get_topology_msg_t  { 
int  msgid; 
int  id; 

ROUTE  r; 

Nodifier.t  modifier; 

}; 


tdefine  US_ATTRIBUTE_GET_SHAPE  1621 
struct  us_attribute_get_shape_msg_t  { 
int  msgid; 
int  id; 

ROUTE  r; 

Hodifier_t  modifier; 

}; 


tdefine  US_ATTRIBUTE_GET_PATTERI  1622 
struct  us_attribute_get_pattern_msg_t  { 
int  msgid; 

ROUTE  r; 

Nodifier_t  modifier; 

}; 

tdefine  US_ATTRIBUTE_GET_MATERIAL  1623 
struct  us_attribute_get_material_t  { 
int  msgid; 

ROUTE  r; 

Hodifier_t  modifier; 

}; 


tdefine  US_ATTRIBUTE_GET_KIIEMATICS  1624 
struct  us_attribute_get_kinematics_t  { 
int  msgid; 

ROUTE  r; 

Nodifier.t  modifier; 

}; 
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tendif 


H.3.6  Interfaces 

#ifndef  UTAP.IITERFACE.DETIIITIOIS 
tdefine  UTAP_IITERFACE_DEFI>ITIOIS 

f include  "generic_defs.h" 
f include  "utap.inf o.model . h" 
tinclude  "utap_data_defs .h" 

//  These  types  must  be  defined  - there  are  stubbed  out  for  nos 
tinclude  "undef ined_types.h" 

/** 

This  header  file  defines  the  interfaces  for  communication  betaeen 
modules  in  the  Generic  C5  Architecture. 

Generic  Telerobotic  Architecture  for  C-5  Industrial  Processes 
contains  modules  of  uhich  the  follosing  have  acronyms: 

NODULES  lANIIG/ACROIYNGS: 

REMOTE : 

RSC  - robot  servo  control 
TOOL  - tool  control 
SEISOR-  sensor  control 
PIO  - programmable  io 
TLC  - task  level  control 
CLC  - closed  loop  control 
DB  - data  base  is  part  of  TLC  k CLC 
VS  - virtual  sensor 
LOCAL : 

TDS  - task  description  and  supervision 

TK  - task  knowledge 

TRD  - trajectory  description 

PTPS  - parent  task  program  sequencer 

TPS  - task  program  sequencer 

01  - operator  interface 

OK  - object  knovledge 

OC  - object  calibration 

ON  - object  modeling 

SGD  - status  graphics  displays 

SS  - subsystem  simulators 

ADS  - analysis  and  diagnosis 

*/ 

A little  table  of  contents; 


GENERIC : 

101 

- 

199 

ERROR; 

-100 

- 

-200 

ROBOT.SERVO : 

200 

- 

299 

TOOL: 

300 

- 

399 

SEISOR: 

400 

- 

499 

PIO: 

500 

- 

599 

TLC: 

600 

- 

699 

DB: 

700 

- 

799 

VS: 

800 

- 

899 

TDS: 

1000 

- 

1099 

TK: 

1100 

- 

1199 

TRD: 

1200 

- 

1299 

PTPS: 

1300 

- 

1399 

TPS: 

1400 

- 

1499 

01: 

1500 

- 

1599 
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OK 

1600  - 

1699 

OC 

1700  - 

1799 

ON 

1800  - 

1899 

SGD: 

1900  - 

1999 

ADS: 

2000  - 

2099 

SS; 

2100  - 

2199 

♦/ 

// 

// 

//  Generic  US  messages  to  any  Module 

//  To  be  verified  against  RIA  Standard  R15-06-1992 

// 


tdefine  GEIERIC  100 


//  Hardvare  State/Node  Control 
tdefine  US.STARTUP  101 
struct  us_startup_msg_t  { 
int  msgid; 

}; 


tdefine  US.SHUTDOHI  102 
struct  us_shutdoBn_msg_t  { 
int  msgid ; 

}; 


tdefine  US.RESET  103 
struct  us_reset_msg_t  { 
int  msgid ; 
enum  { HU  = 1 , 

SU  = 2, 

} type; 
long  mask ; 

}; 


tdefine  US.EIABLE  104 
struct  us_enable_msg_t  { 
int  msgid ; 
int  axis; 


tdefine  US.DISABLE  105 
struct  us_disable_msg_t  { 
int  msgid; 
int  axis; 


tdefine  US.ESTOP  106 
struct  us_estop_msg_t  { 
int  msgid ; 

}; 


//hardware  powered  up  into  safe  state 


//  bit-map  of  units  to  reset 


//  sensor/effector(s)  turned  on 


//  sensor/effectorCs)  turned  off 


//  emergency  sensor/effector  off 


//  Software  State/Node  Control 
tdefine  US.START  107 
struct  us_start_nisg_t  { 
int  msgid; 

}; 


tdefine  US_ST0P  108 
struct  us_stop_msg_t  { 
int  msgid ; 

}; 


tdefine  US.ABORT  109 
struct  us_abort_msg_t  { 
int  msgid; 

}; 


110 


UTAP/WD  Standard  Interface  Environment 


idefine  US.HALT  110 
struct  U8_halt_m8g_t  { 
int  msgid; 

}; 

tdefine  US.IIIT  111 
struct  us_init_msg_t  { 
int  msgid; 

}; 

fdefine  US.HOLD  112 
struct  us_hold_msg_t  { 
int  msgid ; 

}; 

fdefine  US.PAUSE  113 
struct  us_pause_msg_t  { 
int  msgid ; 

}; 

fdefine  US.RESUHE  114 
struct  U8_resume_msg_t  { 
int  msgid; 

}; 

fdefine  US.ZERO  115 
struct  u8_zero_m8g_t  { 
int  msgid; 

long  mask;  //  bit-map  of  units  to  zero 

}; 


fdefine  US.BEGII.SIIGLE.STEP  116 
struct  U8_begin_8ingle_step_m8g_t  { 
int  msgid; 

//  require  more  explicit  info  here 

}; 

fdefine  US.IEXT.SIIGLE.STEP  117 
struct  us_next_8ingle_8tep_msg_t  { 
int  msgid; 

//  require  more  explicit  info  here 

}; 


fdefine  US_CLEAR_SIIGLE_STEP  118 
struct  us_clear_8ingle_step_msg_t  { 
int  msgid ; 

}; 


//  Interface  Programming  Constructs 
fdefine  US.BEGII.BLOCK  119 
struct  us_begin_block_ra8g_t  { 
int  msgid; 

}; 


fdefine  US.EID.BLOCK  120 
struct  us_end_block_m8g_t  { 
int  msgid; 

}; 


fdefine  US.BEGII.PLAl  121 
struct  us_begin_plan_msg_t  { 
int  msgid; 
char  name [128] ; 
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•define  US_EID_PLAI  122 
struct  U8_end_plan_msg_t  { 
int  msgid; 

}; 

•define  US_USE_PLAH  123 
struct  us_use_plan_iiisg_t  { 
int  DSgid; 

}; 


•define  US.BEGIB.NACRO  124 
struct  us_begin_macro_msg_t  { 
int  msgid; 
char  name [128]; 

}; 


•define  US_EID_NACRO  125 
struct  us_end_macro_msg_t  { 
int  msgid ; 

}; 


•define  US_USE_MACRO  126 
struct  u8_execute_macro_msg_t  { 
int  msgid; 
char  name [128] ; 

}; 

•define  US_BEGII_EVEIT  127 
struct  us_begin_event_msg_t  { 


int  msgid; 
char  name [128] ; 

enum  { .FROM.START  = 1, 

_FR0H_EID  = 2 , 

_AT_TIHE  = 3, 

_AT_HARK  = 4 , 

_WITH_EXCEPTIOI  = 5, 

} type; 

TIME  t; 


//  require  step  number  in  block? 


•define  US_EID_EVEIT  128 
struct  us_end_event_m8g_t  { 
int  msgid ; 

}; 


•define  US.HARK.BREAKPOIIT  129 
struct  u8_mark_breakpoint_msg_t  { 

int  msgid;  //  softsare  pause 

}; 

•define  US_HARK_EVEIT  130 
struct  us_mark_event_msg_t  { 
int  msgid ; 

char  name[128];  //  place  event  marker 

}; 

•define  US_GET_SELECTIOI_ID  131 
struct  U8_get_8election_id_msg_t  { 
int  msgid ; 

char  name [128];  //  if  symbolic  get  device  or  module  numeric  id 

}; 

•define  US_POST_SELECTIOI_ID  132 
struct  U8_po8t_8election_id_msg_t  { 
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int  lesgid; 
int  id; 


tdefine  US_USE_SELECTIOB  133 
struct  us_u8e_8election_msg_t  { 
int  msgid; 

int  id;  //  ohich  device  or  module,  start  with  1 

}; 

•define  US_USE_AXIS_MASK  134 
struct  U8_U8e_axis_ma8k_msg_t  { 
int  msgid; 

AxisMask  axis ; 

}; 

//  lee  Message  EXTension  Facility 
tdefine  US_USE_EXT.ALGORITHH  135 
struct  us_use_ext_algorithm_msg_t  { 
int  msgid; 

int  slot ; //  slot  holder 

}; 


tdefine  US_LOAD_EXT_PARAMETER  136 
struct  us_load_ext_parameter_msg_t  { 
int  msgid; 

int  slot ; //  slot  id 

}; 


tdefine  US_GET_EXT_DATA_VALUE  137 
struct  us_get_ext_data_value_msg_t  { 
int  msgid; 

int  slot ; //  slot  id 

ROUTE  r; 

}; 


tdefine  US_POST_EXT_DATA_VALUE  138 
struct  us_post_ext_data_value_m8g_t  { 
int  msgid; 

int  slot;  //  slot  id 

void  • data;  //  pointer  into  heap 

}; 


tdefine  US_SET_EXT_DATA_VALUE  139 
struct  us_set_ext_data_value_msg_t  { 
int  msgid; 

int  slot;  //  slot  id 

void  • data;  //  pointer  into  heap 

}; 


//  Status 

tdefine  US_LOAD_STATUS_TYPE  140 
struct  us_load_statu8_m8g_t  { 
int  msgid; 
enum  { SERVO , 

ALIVE, 

ACK.IACK, 

lOIE, 

} type; 


}; 


tdefine  US_LOAD_STATUS_PERIOD  141 
struct  us_load_8tatu8_period_msg_t  { 
int  msgid; 

double  time;  //  seconds 
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}; 


tdefine  US.GEEERIC.STATUS.REPORT  142 
struct  u8_generic_status_report_t  { 

int  msgid; 

STATUS.TYPE  status; 

double  progress;  //  percent  completion 

enum  { 

exception  = -2, 
failed  = -1 , 
incomplete  = 0, 
succeeded  = 1 , 
partial.success  = 2, 
progressing  = 3, 

} type; 
enum  { 


exception_process_lost  = 10, 

exception_deadlock  = 11, 

exception_resource_unavailable  = 12, 
exception_re80urce_tip_deunaged  = 13, 
exception_insuff icient_capacity  = 14, 
} explanation; 
void  * command_echo ; 

}; 


// 

//  Errors 

//  First  100  are  negations  of  Posix  errno.h  convention 

// 

tdefine  ERRORS  -200 

tdefine  US_ERROR_COmAID_IOT_IHPLEMEITED  -200 
struct  us_error_command_not_implemented_msg_t  { 
int  msgid ; 

}; 


•define  US_ERRDR_C0»1AID_EITRY  -201 
struct  us_error_command_ontry_msg_t  { 
int  msgid; 
int  field.num; 

}; 

•define  US_ERROR_DUPLICATE_IAHE  -202 
struct  us_error_duplicate_name_msg_t  { 
int  msgid; 

}; 


•define  US_ERROR_BAD_DATA  -203 
struct  us_error_command_bad_data_msg_t  { 
int  msgid; 
int  field.num; 

}; 


•define  US_ERR0R_10_DATA_AVAILABLE  -204 
struct  us_error_no_data_available_msg_t  { 
int  msgid ; 
int  field_num; 

}; 


•define  US_ERROR_SAFETY_VIOLATIOI  -205 
struct  us_error_8afety_violation_msg_t  { 
int  msgid ; 
int  field.num; 

}; 

•define  US_ERROR_LIHIT_EXCEEDED  -206 
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struct  us_error_limit_exceeded_rasg_t  { 
int  msgid; 

Attribute_t  attr; 

}; 


♦define  US.ERROR.OVER.SPECIFIED  -207 
struct  us_orror_over_8pecif ied_insg_t  { 
int  msgid; 
int  axis_number: 

}; 


♦define  US_ERROR_UIDER_SPECIFIED  -208 
struct  us_error_under_8pecified_msg_t  { 
int  msgid ; 

}; 


// 

// 

II  US  messages  to  ROBOT  SERVO  */ 

// 

♦define  AXIS.SERVO  200 
//  Hode  Definitions 

♦define  US_AXIS_SERVO_USE_AIGLE_UIITS  201 
struct  us_axis_8ervo_u8e_angle_units_msg_t  { 
int  msgid; 

}; 


♦define  US_AXIS_SERV0_USE_RADIAI_U1ITS  202 
struct  u8_axi8_servo_u8e_radian_unit8_msg_t  { 
int  msgid; 

}; 

♦define  US_AXIS_SERV0_USE_ABS_P0SITI0I_(10DE  203 
struct  us_ajci8_8ervo_u8e_abs_position_mode_msg_t  { 
int  msgid; 

}; 

♦define  US_AXIS_SERV0_USE_REL_P0SITI0I_H0DE  204 
struct  us_axi8_8ervo_use_rel_position_mode_msg_t  { 
int  msgid; 

}; 

♦define  US_AXIS_SERV0.USE.ABS_VEL0CITY_M0DE  205 
struct  u8_axi8_servo_u8e_ab8_velocity_mode_msg_t  { 
int  msgid; 

}; 

♦define  US_AXIS_SERVO_USE_REL_VELOCITY_MODE  206 
struct  us_axi8_8ervo_use_rel_velocity_mode_msg_t  { 
int  msgid; 

}; 

♦define  US_AXIS_SERVO_USE_PID  207 
struct  us_axi8_servo_use_pid_msg_t  { 
int  msgid; 
int  joint .mask; 

}; 

♦define  US.AXIS.SERVO.USE.FEEDFORWARD.TORQUE  208 
struct  us.axis.servo.use.ff.msg.t  { 
int  msgid; 

}; 

♦define  US.AXIS.SERVO.USE.CURREIT  209 
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struct  u8_axis_servo_u8e_current_msg_t  { 
int  msgid; 

}; 

tdefine  US_AXIS_SERVO_USE_VOLTAGE  210 
struct  us_axis_servo_u8e_voltage_in8g_t  { 
int  msgid ; 

}; 


//  dof  of  in  shich  to  apply  springs 
//  spring  gains 

//  max  velocity  due  to  springs 


tdefine  US_AXIS_SERVO_USE_STIFFIESS  211 
struct  us_ajcis_8ervo_use_stiffness_msg_t  { 
int  msgid; 
int  spSelVect ; 
double  * gains ; 
double  * spMaxVel; 

}; 


tdefine  US_AXIS_SERVO_USE_COMPLIAICE  212 
struct  us_axi8_8ervo_u8e_compliance_msg_t  { 
int  msgid; 

}; 

tdefine  US_AXIS_SERVO_USE_IMPEDAICE  213 
struct  us_axis_8ervo_use_impedance_msg.t  { 
int  msgid; 

}; 

tdefine  US_AXIS_SERVO_START_GRAVITY_COMPEiSATIOI  214 
struct  us_axis_servo_start_gravity_compensation_msg_t  { 
int  msgid; 

}; 

tdefine  US_AXIS_SERV0_ST0P_GRAVITY_C0HPEISATI0I  215 
struct  us_axis_servo_stop_gravity_compen8ation_msg_t  { 
int  msgid; 

}; 

tdefine  US_AXIS_SERV0_L0AD_D0F  216 
struct  u8_axi8„8ervo_load_dof_m8g_t  { 
int  msgid; 
int  dof; 

}; 

tdefine  US_AXIS_SERVO_LOAD_CYCLE_TIHE  217 
struct  u8_axis_8ervo_load_cycle_time_msg_t  { 
int  msgid ; 
double  time; 

}; 

tdefine  US_AXIS_SERVO_LOAD_PID_GAII  218 
struct  u8_axi8_8ervo_load_pid_gain_msg_t  { 
int  msgid; 
int  joint.mask; 


double 

*p: 

// 

load  proportional  gain 

double 

•i; 

// 

load  integral  gain 

double 

•d; 

// 

load  derivative  gain 

}; 

tdefine  US_AXIS_SERV0_L0AD_J0IIT_LIHIT  219 
struct  us_axis_servo_load_joint_limit_msg_t  { 
int  msgid ; 
int  axis_bit_mask ; 

double  *jmaxLimit;  //  maximum  joint  software  limits 

double  * jminLimit ; //  minimum  joint  software  limits 

}; 
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Wefine  US_AXIS_SERVO_LOAD_VELOCITY_LIHIT  220 
struct  u8_axis_8ervo_load_velocity_limit_msg_t  { 
int  msgid; 
int  axis_bit_mask ; 

double  •jvelLimit;  //  maximum  joint  velocity  limits 

}; 


•define  US_AXIS_SERVO_LOAD_GAII_LIHIT  221 
struct  us_axis_servo_load_joint_gain_limit_mag_t  { 
int  msgid; 
double  •jaGain; 

}; 


•define  US_AXIS_SERVO_LOAD_DAHPIIG_VALUES  222 
struct  us_axis_servo_load_damping_values_msg_t  { 
int  msgid; 

double  ejaDeunp;  //  damping  values  for  impedance 

}; 


// 

//  Command  Data  Node 

// 

•define  US.AXIS.SERVO.HOME  250 
struct  us_axis_servo_home_msg_t  { 
int  msgid ; 
int  axis; 

}; 

•define  US_AXIS_SERVO_SET_BRAKES  251 
struct  u8_axis_servo_set_brakes_msg_t  { 
int  msgid; 
int  axis_bit_mask ; 

}; 

•define  US_AXIS_SERVO_CLEAR_BRAKES  252 
struct  us_axi8_8ervo_clear_brakos_msg_t  { 
int  msgid; 
int  axis.bit.mask ; 

}; 

•define  US_AXIS_SERVO_SET_TORQUE  253 
struct  u8_axis_8ervo_set_torque8_msg_t  { 
int  msgid; 
int  axis.bit.mask ; 
double  *joint_torques; 

}; 


•define  US_AXIS_SERVO_SET_CURREIT  254 
struct  u8_axi8_8ervo_8et_current_m8g_t  { 
int  msgid; 

double  ejoint.currents ; 

}; 


•define  US_AXIS_SERVO_SET. VOLT AGE  255 
struct  us_axis_servo_8et_voltage_m8g_t  { 
int  msgid ; 

double  • joint_voltages ; 

}; 


•define  US_AXIS_SERVO.SET_POSITIOI  256 
struct  us_axi8_servo_8et_position_msg_t  { 
int  msgid; 

double  ejoint.position ; 

}; 


•define  US_AXIS_SERVO_SET_VELOCITY  257 
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struct  U8_axi8_8ervo_8et_volocity_msg_t  { 
int  msgid ; 

double  •joint_velocity ; 

}; 


tdefine  US_AXIS_SERVO_SET_ACCELERATIOI  258 
struct  us_axis_8ervo_set_acceleration_msg_t  { 
int  msgid ; 

double  • joint_acceleration ; 

}; 


#define  US_AXIS_SERVO_SET_FORCES  259 
struct  us_axis_servo_set_force_msg_t  { 
int  msgid; 

double  *joint_force ; 

}; 


tdefine  US_AXIS_SERVO_JOG  260 
struct  us_ajcis_8ervo_jog_m8g_t  { 
int  msgid; 
int  axis ; 
double  speed; 


tdefine  US_AXIS_SERV0_J0G_ST0P  261 
struct  U8_axis_servo_jog_stop_msg_t  { 
int  msgid; 
int  axis ; 

}; 


// 

// 

//  US  messages  to  TOOL 

// 

tdefine  TOOL  300 
//  Spindle 

tdefine  US_SPIIDLE_RETRACT_TRAVERSE  310 
struct  U8_8pindle_retract_traver8e_msg_t  { 
int  msgid ; 

}; 


tdefine  US_SPIIDLE_LOAD_SPEED  311 
struct  u8_load_spindle_speed_m8g_t  { 
int  msgid; 
double  r; 


tdefine  US_SPIIDLE_START_TURIIIG  312 
struct  us_8tart_8pindle_msg_t  { 
int  msgid ; 

enum  {CLOCKWISE  = 1 , 

COUITERCLOCKWISE  = 2 , 

} direction; 

}; 

tdefine  US.SPIIDLE.STOP.TURIIIG  314 
struct  us_8top_8pindle_turning_m8g_t  { 
int  msgid; 

}; 


tdefine  US„SPIIDLE_RETRACT  315 
struct  us_spindle_retract_msg_t  { 
int  msgid; 

}; 
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fdofine  US.SPIIDLE.ORIEIT  316 
struct  u8_orient_8pindle_msg_t  { 
int  msgid; 
double  orientation; 
double  direction; 

}; 

tdefine  US_SPI1DLE_L0CK_Z  317 
struct  u8_lock_8pindle_z_msg_t  { 
int  msgid ; 

}; 


#define  US_SPIIDLE_USE_FORCE  318 
struct  UE_u8e_8pindle_f orce.msg.t  { 
int  m8gid; 

}; 


•define  US_SPIIDLE_USE_IO_FORCE  319 
struct  us_u8e_no_8pindle_force_m8g_t  { 
int  msgid; 

}; 


//  FIob  Control:  Hist/Coolant/Abrasive  Spray 
•define  US_FLOW_START_MIST  320 
struct  us_floB_8tart_mi8t_msg_t  { 
int  msgid; 

}; 


•define  US.FLOW.STOP.NIST  321 
struct  us_floB_8top_mi8t_msg_t  { 
int  msgid ; 

}; 


•define  US_FL0«.START_FL00D  322 
struct  us_floB_8tart_flood_m8g_t  { 
int  msgid ; 

}; 


•define  US_FL0M_ST0P_FL00D  323 
struct  u8_floB_8top_f lood_msg_t{ 
int  msgid; 

}; 


•define  US_FLOW_LOAD_PARAMETERS  324 
struct  u8_floB_load_parameters_m8g_t  { 
int  msgid; 
enum  { none , 

floB_rate , 
viscosity , 
consistency, 
thickness , 
temperature , 

} param; 

double  value.rate; 

enum  { beam  = 0x1 , 
mi8t=0x2 , 
spray  = 0x4 , 

} floB; 

enum  { stream, 
pulsed , 

} action; 


// 
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// 

//  SEISOR  NODULE 

// 

tdefine  SEBSOR  400 

// 

//  Sensor  Node  Generics 

// 

•define  US_START_TRAISFORN  401 
struct  us_start_transfonn_msg_t  { 
int  msgid; 

}; 


•define  US.STOP.TRAISFORN  402 
struct  us_stop_transfonn_msg_t  { 

int  msgid;  //  same  as  loading  identity  transform 

}; 

•define  US.START.FILTER  403 
struct  us_8tart_filter_msg_t  { 
int  msgid ; 

}; 

•define  US_STOP_FILTER  404 
struct  us_stop_f ilter_msg_t  { 

int  msgid;  //  same  as  loading  no  filter 

}; 


•define  US_SEIS0R_USE_NEASURENEIT_U1ITS  405 
struct  us_sensor_use_measurement_units_msg_t  { 
int  msgid; 

Neasurement_units_type  array_units ; 

}; 


// 

//  Sensor  Parameter  Generics 

// 

•define  OS_SE1SOR_LOAD_SANPLIIG_SPEED  406 
struct  tts_8ensor_load_sampling_speed_msg_t  { 
int  msgid; 
double  value ; 

}; 


•define  US.SEBSOR.LOAD.FREQUEICY  407 

struct  us_sensor_load_frequency_msg_t  { 
int  msgid ; 
double  value ; 

}; 


•define  US_SE1S0R_L0AD_TRAISF0RN  408 
struct  us_8en8or_load_transform_msg_t  { 
int  msgid ; 

double  x,y ,z,el ,e2,e3;  //  transforms 

}; 


•define  US_SEISOR_LOAD_FILTER  409 
struct  u8_8ensor_load_f ilter_m8g_t  { 
int  msgid; 
enum  { BOIE  = 0, 

LOW.PASS  = 1, 

HI.PASS  = 2, 

} type; 

double  f ilter.f requency ; 
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}; 


// 

//  Generic  Coiiunands 

// 

•define  US_SEISOR_GET_READIIG  410 
struct  us_8en8or_get_reading_m8g_t  { 
int  msgid; 

ROUTE  r;  //  type  of  values:  max,  min,  avg 

//  and  Bhere  it  goes 

}; 


•define  US_SEISOR_GET_ATTRIBUTES_READIiG  411 
struct  us_sensor_get_attributes_reading_m8g_t  { 
int  msgid; 

ROUTE  r; 

Attribute_t  attr;  //  reading  attributes,  e.g.,  force  | torque 

}; 


//  lot  sure  ¥6  need  this 
•define  US_VECTOR_SEISOR_GET_READIIG  412 
struct  us_vector_8en8or_get_reading_msg_t  { 
int  msgid ; 

ROUTE  r; 


}; 


II  Force  Torque  Sensor 
•define  US_FT_SEISOR_POST„READIIG  413 
struct  us_ft_8en8or_po8t_reading_msg_t  { 
int  msgid; 
int  health; 

double  ef ; //  force  vector,  based  on  dof 

double  *t ; //  torque  vector,  based  on  dof 

}; 


//  Scalar  Probe 

•define  US_SCALAR_SEISOR.POST_READIIG  414 
struct  u8_8calar_8ensor_po8t_reading_m8g_t  { 
int  msgid; 
double  upper.limit; 
double  lo¥er_limit; 

}; 


//  ID  Vector  Probe 

•define  US_VECT0R_SE1S0R_P0ST_READIIG  415 
struct  us_VECT0R_8en8or_po8t_reading_msg_t  { 
int  msgid; 
double  evector; 

}; 


//  Generic  2D  Interface 

//  e.g..  Range  or  Tactile  Array 

// 

//  Node  Control  to  Sensor 

// 

•define  US_2D_SEIS0R_L0AD_ARRAY_PATTERI  416 
struct  us_2D_8en8or_load_array_pattern_m8g_t  { 
int  msgid; 

long  array.pattem ; //  bit-map  of  sensors  enabled 

float  period;  //  period  of  sampling 

}; 


•define  US_2D_SEIS0R.USE_ARRAY_TYPE  417 
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struct  us_2D_8onsor_use_array_type_msg_t  { 
int  msgid; 

enum  { OIE.SHOT  = 1, 

FLOOD  = 2 , 

} type; 

}; 


// 

//  Input  CoRunand  to  2D  Sensor 

// 

tdefine  US_2D.SEBS0R_GET_READIIG  418 
struct  us_2D_sensor_get_reading_insg_t  { 
int  msgid; 

ROUTE  r; 

Nodifier.t  mod; 

}; 


// 

//  Output  Data  from  2D  Sensor 

// 

#define  US_2D_SEIS0R_P0ST_READIIG  419 
struct  us_2D_sensor_post_reading_msg_t  { 
int  msgid; 
int  rovs ; 
int  cols; 

double  *array .values ; II  array  of  values 

}; 


//  Specific  2D  Image  Processing  Sensor  Interface 
•define  US_IMAGE_USE_FRAI1E_GRAB_H0DE  420 
struct  us_image_sensor_use_frame_grab_mode_msg_t  { 
int  msgid; 

}; 


•define  US_IHAGE_USE_HISTOGRAM_HODE  421 
struct  us_image_sensor_use_histogram_mode_msg_t  { 
int  msgid ; 

}; 


•define  US_IHAGE_USE.CE1TR0ID_H0DE  422 
struct  us_image_sensor_use_centroidjnode_msg_t  { 
int  msgid; 

}; 


•define  US_IIIAGE_USE_GRAY_LEVEL_HODE  423 
struct  us_image_sensor_use_gray_level_mode_msg_t  { 
int  msgid; 

}; 


•define  US_IMAGE_USE_TRESHOLD_HODE  424 
struct  us_image_sensor_use_threshold_mode„msg_t  { 
int  msgid; 
double  *threshold; 

}; 


•define  US_IHAGE_COHPUTE_SPATIAL_DERIVATIVES_HODE  425 
struct  us_image_sensor_compute_spatial_dorivativos_msg_t  { 
int  msgid; 

}; 


•define  US_INAGE_COHPUTE_TEHPORAL_DERIVATIVES_HODE  426 
struct  us_image_sensor_compute_temporal_derivatives_msg_t  { 
int  msgid ; 

}; 

•define  US.IMAGE.USE.SEGHEITATATIOB.HODE  427 
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struct  u8_iinage_sen8or_U8e_8eginentation_iBode_tn8g_t 
int  msgid; 

}; 

#define  US_IHAGE_USE_RECOGIITIOI_MODE  428 
struct  us_iinage_8ensor_u8e_recognition_raode_msg_t 
int  msgid; 

OBJECT  to_recognize ; 

}; 

tdefine  US_IHAGE_COMPUTE_RAIGE_HODE  429 
struct  u8_image_8en8or_compute_range_mode_msg_t  { 
int  msgid; 

}; 

♦define  US_IMAGE_COHPUTE_FLOW_MODE  430 
struct  us_image_sensor_compute_floB_mode_msg_t  { 
int  msgid; 

}; 

♦define  US.IMAGE.LOAD.CALIBRATIOl  431 
struct  us_image_8ensor_calibration_msg_t  { 
int  msgid; 

int  calibration_8tate ; 

int  cur8or_value ; 

float  cx; 

float  cy; 

float  sx; 

float  ncx; 

float  nf X ; 

float  dx; 

float  dy; 

float  dxp; 

float  f ocal.length; 

float  distort; 

}; 

// 

//  Data  Node 

// 

♦define  US_IHAGE_SET_POSITIOI  432 
struct  us_image_8et_8en8or_position_msg_t  { 
int  msgid; 
float  x; 
float  y; 
float  z; 
float  pan; 
float  tilt; 
float  zoom; 

}; 

♦define  US_IHAGE_ADJUST_POSITIOI  433 
struct  us_image_adju8t_position_m8g_t  { 
int  msgid; 

enum  { X=1 , 

Y=2, 

Z=4, 

PAI=5 , 

TILT=6, 

Z00N=7 , 

} axis ; 
int  i ; 

double  evalue ; 

}; 


{ 


{ 


//  cursor  value 
//  X center  of  image  plane 
//  y center  of  image  plane 
//  uncertainty  scale  factor 

//  number  of  sensor  elements  in  camera  x direction 

//  resolution  of  image  frame  - x direction 

//  X sensing  area  (designated  in  camera  specs)/  ncx 

//  2*  (y  sensing  area)/ncy 

//  dx(ncx/nfx)  for  camera 

//  focal  length  of  camera 

//  distortion  factor  for  camera 


//  camera  position 

//  camera  orientation 


//  joint  =>  l=jointl,  2=joint2,4=joint3. . 
//  Cartesian  =>  l=x,  2=y,  4=z 
//  depends  on  mode  whether  world  or  tool 


//  note:  no  data  entry 
//  l=increment,  -l=decrement , 0=8et 
//  if  amount=0,  system  decides 
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•define  US_IHAGE_ADJUST_FOCUS  434 
struct  u8_iinage_adjust_focus_iiisg_t  { 
int  msgid; 
int  i ; 

double  increment ; 

}; 


•define  US_IMAGE.POST_SPECIFICATIOH  435 
struct  us_image_post_8pecif ication  { 
int  msgid; 

STATUS.TYPE  status ; 
int  nuro_of .cameras ; 
int  calibration.state ; 
int  xpixels; 
int  ypixels; 
enum  { 

STATIOIARY, 

NOVIIG, 

} type; 

TRAISFORH  * base; 

}; 

•define  US_IHAGE_POST_PIXEL.MAP_READIIG  436 
struct  us_image_post_pixel_map_reading  { 
int  msgid; 

STATUS.TYPE  status; 

TINE  timestamp; 
int  num.cameras ; 
int  ross; 
int  cols; 
int  •image.data; 

}; 


//  l^increment,  -l=decrement , 0=8et 
//  if  araount~0,  system  decides 


//  reflect  image  data  origin 
//  number  of  cameras 


//  image  data  vould  follov  here 


•define  US_INAGE_POST_HISTOGRAN_R£ADIIG  437 
struct  us_image_post_histogram_reading  { 
int  msgid; 

STATUS.TYPE  status; 

TINE  timestamp; 
int  num.cameras ; 
int  ro8s ; 
int  cols; 
int  eimage.data; 

}; 


//  reflect  image  data  origin 
//  number  of  cameras 

//  image  data  sould  folios  here 


•define  US_INAGE_POST_XY_CHAR_READIIG  438 
struct  us_image_po8t_xy_char_reading  { 
int  msgid; 

STATUS.TYPE  status; 

TINE  timesteimp; 
int  num.cameras ; 
int  ross ; 
int  cols; 
int  *image_data; 

}; 


//  reflect  image  data  origin 
//  number  of  cameras 


//  image  data  sould  folios  here 


•define  US_INAGE_POST_BYTE_SYNBOLIC_READIIG  439 
struct  us_image_post_byte_symbolic_reading  { 
int  msgid; 

STATUS.TYPE  status; 

TINE  timestamp; 
int  num.cameras ; 
int  ross ; 
int  cols; 
int  eimage.data; 

}; 


//  reflect  image  data  origin 
//  number  of  cameras 


//  image  data  sould  folios  here 
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tdafine  US_IMAGE_POST_TRESHDLD_READIIG  440 
struct  us_image_post_threshold_reading  { 
int  msgid; 

STATUS.TYPE  status; 

TIME  timestamp;  //  reflect  image  data  origin 

int  num_c^uneras ; //  number  of  cameras 

int  rose ; 
int  cols; 

int  *image_data;  //  image  data  oould  folios  here 

}; 

•define  US.IMAGE_POST_SPATIAL_DERIVATIVE_READIIG  441 
struct  us_image_post_spatial_derivative_reading  { 
int  msgid; 

STATUS.TYPE  status; 

TIME  timestamp;  // 

int  num_cameras;  // 

int  roBS ; 
int  cols ; 

int  *image_data;  II 

}; 


reflect  image  data  origin 
number  of  cameras 

image  data  sould  folios  here 


•define  US_IMAGE_POST_TEMPORAL_DERIVATIVE_READIIG  442 
struct  us_image_post_torapor^d_derivative_reading  { 
int  msgid; 

STATUS.TYPE  status; 

TIME  timestamp;  //  reflect  image  data  origin 

int  num.cameras ; //  number  of  cameras 

int  rose ; 
int  cols; 

int  *image_data;  //  image  data  sould  folios  here 

}; 


•define  US.IMAGE.POST.RECOGIITIOI.READIIG  443 
struct  us.image.post.recognition.reading  { 
int  msgid ; 

STATUS.TYPE  status; 

TIME  timestamp;  //  reflect  image  data  origin 

int  num.cameras;  //  number  of  cameras 

int  roBS ; 
int  cols; 

int  *image.data;  //  image  data  sould  folios  here 

}; 


•define  US.IMAGE.POST.RAIGE.READIIG  444 
struct  us. image. post. range. reading  { 
int  msgid; 

STATUS.TYPE  status; 

TIME  timestamp;  //  reflect  image  data  origin 

int  num.cameras;  //  number  of  cameras 

int  roBs ; 
int  cols; 

int  *image.data;  II  image  data  sould  folios  here 

}; 


•define  US.IMAGE.POST.FLOH.READIIG  445 
struct  us. image. post. floB. reading  { 
int  msgid; 

STATUS.TYPE  status; 

TIME  timestamp;  //  reflect  image  data  origin 

int  num.cameras;  //  number  of  cameras 

int  ross ; 
int  cols; 

int  *image.data;  //  image  data  sould  folios  here 

}; 
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// 

// 

//  PIO;  SEISOR,  ROBOT  AXIS/JOIIT,  TOOL 

// 

tdefine  PROGRAHHABLE.IO  500 

// 

//  Control 

// 

tdefine  US_PIO_EIABLE  500 
struct  us_pio_enable_msg_t  { 
int  msgid ; 
int  channel; 

}; 

tdefine  US.PIO.DISABLE  501 
struct  us_pio_disable_msg_t  { 
int  msgid; 
int  channel; 

}; 

tdefine  US_PIO_SET_MODE  504 
struct  us_pio_set_mode_msg_t  { 
int  msgid ; 
enum  { IIPUT=1 , 

0UTPUT=2 , 

} direction; 

}; 

tdefine  US_PIO_COITROL_WRITE  505 
struct  us_pio_control_urite_msg_t  { 
int  msgid ; 


enum  { UII_2_HALF  = 1 , 

0II_2_HALF_IEG  = 2, 
BI_2_HALF  = 3, 

U1I_5  = 4, 

0II_5_IEG  = 5, 

BI_5  = 6, 

UII.IO  = 7, 
OTI.IO.IEG  = 8, 

BI_10  = 9, 
■ULL.RAIGE  = 0, 

} info ; 

int  bits.data; 

enum  { FREERUI  = 1 , 
lOFREERUI  =2, 

} run ; 

enum  { SIIGLE.EID  = 1 , 

DIFFEREITIAL  = 2 , 
lULL.REF  = 0, 

} ref  ; 

}; 

tdefine  US_PIO_LOAD_SCALE  511 
struct  us_pio_scale_m8g_t  { 
int  msgid; 
int  channel ; 
double  m ; 
double  b; 

}; 


Programmable  Interfaces 


//  -1  for  all 


//  -1  for  all 


//  similar  to  control.register 
//  set  control  information 
//  unipolar  0 to  ■•'2.5  volts 
//  unipolar  0 to  -2.5  volts 
//  bipolar  -2.5  to  2.5  volts 
//  unipolar  0 to  ■•■5  volts 
//  unipolar  0 to  -5  volts 
//  bipolar  -5  to  5 volts 
//  unipolar  0 to  ■*•10  volts 
//  unipolar  0 to  -10  volts 
//  bipolar  -10  to  10  volts 
//  lull  entry 

//  0,8,10,12,14,16,18,20,... 


//  volts  to  vlaue , scale  factor 
//  offset  value 


126 


UTAP/WD  Standard  Interface  Environment 


// 

//  Data 

// 

•define  US_PIO_DATA_WRITE  506 
struct  us_pio_data_urite_insg_t  { 
int  msgid; 

enum  { SCALE,  RAW  } type; 
union  { 

double  dvalue ; 
int  ivalue ; 

}; 

}; 


•define  US_PIO_DATA_READ  507 
struct  us_pio_data_read_insg_t  { 
int  msgid ; 

enum  { RAW , SCALE  } type ; 
int  channel; 

}; 


•define  US_PIO_BIT_READ  508 
struct  us_pio_bit_read_m8g_t  { 
int  msgid; 
int  channel.num; 
int  bit ; 


•define  US_PIO_BIT_SET  509 
struct  us_pio_bit_8et_msg_t  { 
int  m8gid; 
int  channel.num; 
int  bit ; 


•define  US_PIO_TOGGLE_BIT  510 
struct  us_pio_toggla_bit_msg_t  { 
int  msgid; 
int  channel_num; 
int  bit ; 


•define  US_PI0_P0ST_DATA  512 
struct  u8_pio_input_data_m8g_t  { 
int  msgid; 
enum  { RAW  = 1 , 

SCALED  = 2, 

} type; 
union  { 

unsigned  long  data.register ; //  data  register  read 

double  value; 

}; 

unsigned  long  data.mask;  //  valid  bits 

}; 


// 

// 

// 

// 


TLC  - 


TASK  LEVEL  COITROL  Manipulation 


•define  TASK_LEVEL_COITROL  600 


// 

// 

// 

// 


Task  Level  Control 
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//  Node  Selections  for  Reference  Frames  and  Coordinate  Chains 


•define  US_TLC_USE_JOIIT_REFEREICE_FRAHE  601 
struct  us_tlc_use_joint_reference_frame_msg_t  { 
int  msgid; 

}; 


•define  US_TLC_USE_CARTESIAI_REFEREICE_FRAHE  602 
struct  us_tlc_use_Cstf'te8ian_reference_frame_msg_t  { 
int  msgid; 

}; 


•define  US_TLC_USE_REPRESEITATIOI_UIITS  603 
struct  us_tlc_use_representation_units_msg_t  { 
int  msgid; 

Neasurement_units_type  units;  //  Euler  vs.  Matrix  Transform 

}; 

•define  US_TLC_USE_ABS0LUTE_P0SITI0IIIG_N0DE  604 
struct  us_tlc_use_absolute_po8itioning_mode_msg_t  { 

int  msgid;  //  aka  sorld  coordinate  frame 

}; 


•define  US_TLC_USE_RELATIVE_P0SITI01I1G_H0DE  60S 
struct  us_tlc_relative_positioning_msg„t  { 
int  msgid; 

}; 


•define  US_TLC_USE_miIST_COORDIIATE_FRAME  606 
struct  us_tlc_use_Brist_positioning_msg_t  { 
int  msgid ; 

}; 


•define  US_TLC_USE_TOOL_TIP_COORDIIATE.FRAHE  607 
struct  us_tlc_U8e_tool_positioning_msg_t  { 
int  msgid; 

}; 


•define  US_TLC_CHAIGE_TOOL  608 
struct  us_change_tool_m8g_t  { 
int  msgid; 

int  i;  //  tool  number 

}; 

•define  US_TLC_USE_MODIFIED_TOOL_LEIGTH_OFFSETS  609 
struct  us_tlc_u8e_modif ied_tool_length_offset8_msg_t  { 
int  msgid ; 
int  r; 


•define  US_TLC_USE_IORHAL_TOOL_LEiGTH_OFFSETS  610 
struct  us_tlc_use_normal_tool_length_off sets_msg_t  { 
int  msgid; 

}; 


•define  US_TLC_USE_IO_TOOL_LEIGTH_OFFSETS  611 
struct  us_tlc_use_no_tool_length_offsets_msg_t  { 
int  msgid; 

}; 


•define  US_TLC_USE_KIIEMATIC_RIIG_POSITIOIIIG_HODE  612 
struct  us_tlc_use_kinematic_ring_msg_t  { 
int  msgid ; 

}; 
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//  Notion  Nodes 

fdefine  US_TLC_START_NAIUAL.NOTIOI  613 
struct  us_tlc_start_inanual_motion_m8g_t  { 
int  nsgid; 

AxisNask  axis; 

}; 


•define  US_TLC_STOP_NAIUAL_NOTIOI  614 
struct  us_tlc_stop_inanual_motion_msg_t  { 
int  msgid; 

AxisNask  axis ; 

}; 


•define  US_TLC_START_AUTONATIC_NOTIOI  615 
struct  us_tlc_start_automatic_inotion_msg_t  { 
int  msgid; 

AxisNask  axis; 

}; 


•define  US_TLC_STOP_AUTONATIC_NOTIOI  616 

struct  us_tlc_stop_automatic motion_msg_t  { 

int  msgid; 

AxisNask  axis; 

}; 


•define  US_TLC_START_TRAVERSE_NOTIOI  617 
struct  us_tlc_start_traverse_motion_m8g_t  { 

intjnsgid;  //  freespace 

}; 


•define  US_TLC_STOP_TRAVERSE_NOTIOI  618 
struct  u8_tlc_stop_traverse_motion_msg_t  { 
int  msgid; 

}; 


•define  US_TLC_START_GUARDED_NOTIOI  619 
struct  us_tlc_8tart_guarded_motion_msg_t  { 

int  msgid;  //  obstacle,  constraints 

}; 


•define  US_TLC_STOP_GUARDED.NOTIOI  620 
struct  u8_tlc_stop_guarded_motion_m8g_t  { 
int  msgid; 

}; 


•define  US_TLC_START_CONPLIAIT_NOTIOI  621 
struct  us_tlc_8tart_compliMt_msg_t  { 
int  msgid; 

AxisNask  axis ; 
double  espring; 

}; 


•define  US_TLC_STOP_CONPLIAIT_NOTIOI  622 
struct  u8_tlc_stop_compliant_m8g_t  { 
int  msgid ; 

AxisNask  axis; 

}; 


•define  US.TLC_START_FIIE_N0TI01  623 
struct  u8_tlc_8tart_f ine_m8g_t  { 
int  msgid; 

AxisNask  axis; 

double  errtolerance ; //  amt  of  tolerated  error  in  motion 

int  proximity;  //  bow  close  do  we  come  to  goal  point 

}; 
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tdefine  US_TLC_STOP_FIIE_HOTIOH  624 
struct  us_tlc_stop_fine_nisg_t  { 
int  msgid; 

AxisNask  axis; 

}; 


tdefine  US_TLC_START_HOVE_UITIL_MOTIOI  625 
struct  us_tlc_start_inove_until_ii>sg_t  { 
int  msgid; 

AxisHask  axis ; 
double  econtact.forces ; 

}; 


tdefine  US_TLC_STOP.MOVE_UITIL_MOTIOI  626 
struct  us_tlc_stop_move_until_msg_t  { 
int  msgid; 

AxisNask  axis ; 

}; 


tdefine  US_TLC_START_STAIDOFF_DISTAICE  627 
struct  us_tlc_start_standoff_msg_t  { 
int  msgid ; 

AxisNask  axis ; 
double  edistance; 

}; 


tdefine  US_TLC_ST0P_STA1D0FF_DISTA1CE  628 
struct  us_tlc_stop_standoff_m8g_t  { 
int  msgid ; 

AxisNask  axis ; 

}; 


tdefine  US_TLC_START_FORCE_POSITIOIIIG_NODE  629 
struct  us_tlc_start_force_positioning_msg_t  { 

int  msgid;  //  for  force  reflection 

}; 


tdefine  US_TLC_STOP_FORCE_POSITIOIIIG_NODE  630 
struct  U8_tlc_stop_force_positioning_msg_t  { 

int  msgid;  //  for  force  reflection 

}; 


// 

// 

//  Parameter  Settings 

// 

tdefine  US_TLC_L0AD_D0F  631 
struct  us_tlc_U8e_dof_msg_t  { 
int  msgid; 

int  dof;  //  motion  DOF,  i.e.,  3D  vs  6D 

}; 


tdefine  OS_TLC_LOAD_CYCLE_TINE  632 
struct  u8_load_cycle_time_msg_t  { 
int  msgid ; 
double  time ; 

}; 


tdefine  US_TLC_LOAD_REPRESEITATIOI_UIITS  633 
struct  us_tlc_load_repre8entation_units_m8g_t  { 
int  msgid ; 

Neasnrement_unit8_type  units;  //  Euler  vs.  Natrix  Transform 

}; 


tdefine  US_TLC_LOAD_LEIGTH_UIITS  634 
struct  U8_tlc_load_length_unit8_msg_t  { 
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int  nsgid; 

Ne&surement_uiiits_type  units;  //  Meters  vs.  mm  vs.  inches 


tdefine  US_TLC_LOAD_RELATIVE_POSITIOIIIG  635 
struct  us_tlc_load_relative_positioning_msg_t  { 
int  msgid; 

TRAISFORM  * t; 

}; 

tdefine  US_TLC_ZERO_RELATIVE_POSITIOIIIG  636 
struct  u8_tlc_zero_relative_positioning_msg_t  { 
int  msgid; 

}; 


tdefine  US_TLC_ZERO_PROGRAM_ORIGII  637 
struct  us_tlc_zerot_program_origin_msg_t  { 
int  msgid; 

TRAISFORM  * t; 

}; 


tdefine  US_TLC_LOAD_KIIEMATIC_RIIG_POSITIOIIIG_MODE  638 
struct  us_tlc_load_kinematic_ring_msg_t  { 
int  msgid; 

Measurement.units.type  units; 


.Base 

s 

0x0000001 

.TOOL 

= 

0x0000002 

.SEISOR.FUSIOI 

S 

0x0000004 

//  RHS 

.DELTA 

= 

0x0000010 

.OBJECT 

0x0000020 

.OBJECTBASE 

0x0001000 

.0BJECT0FFSET2 

= 

0x0002000 

.0BJECT0FFSET3 

B 

0x0003000 

.0BJECT0FFSET4 

S 

0x0004000 

} mask ; 


tdefine  US_TLC_LOAD_BASE_PARAMETERS  639 
struct  u8_tlc_load_base_parameters_msg_t  { 
int  msgid; 

TRAISFORM  * trBase; 


tdefine  US_TLC_LOAD_TOOL_PARAMETEBS  640 
struct  u8_tlc_load_tool_parameter8_msg_t  { 
int  msgid; 
char  name [128]  ; 
double  dx,  dy,  dz ; 
double  ux , uy , uz ; 
double  normal.threshold ; 
double  tangential.threshold; 
ORIEITATIOI.TYPE  heading; 

}; 

tdefine  US_TLC_LOAD_OBJECT  641 
struct  u8_tlc_load_object_m8g_t  { 
int  msgid; 

OBJECT  obj.id; 

TRAISFORM  * t ; 


//  tool  name 

//  tooling  added  translation  against  edge 

//  Euler  angles  for  tooling  angle 

//  amount  of  normal  force 

//  amount  of  tangential  force 

//  Bhat  is  the  heading  of  the  tool  tip 


}; 


tdefine  US_TLC_L0AD_0BJECT_BASE  642 
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struct  u8_tlc_load_object_baso_m8g_t  { 
int  msgid; 

TRAISFORM  ♦ t; 


}; 


#define  US_TLC_LOAD_OBJECT_OFFSET  643 
struct  us_tlc_load_object_offset„rasg_t  { 
int  msgid ; 
int  i; 

TRAISFORM  • t; 

}; 

fdefine  US_TLC_LOAD_DELTA  644 
struct  us_tlc_load_delta_msg_t  { 
int  msgid ; 
enum  { _SIIE_WAVE_, 

_DITHER_, 

_IULL_ , 

} delta; 

double  magnitude; 
double  frequency; 

}; 


•define  US_TLC_LOAD_OBSTACLE_ VOLUME  645 
struct  us_tlc_load_ob8tacle_volume_msg_t  { 
int  msgid; 
int  i ; 

TRAISFORM  « t ; 

}; 


//  Dynamical  Control 
•define  US.TLC.LOAD.IEIGHBORHOOD  646 
struct  us_tlc_load_blending_msg_t  { 
int  msgid; 

double  dist ; //  error 

BLEID.TYPE  blend;  //  uhat 

}; 

•define  US_TLC_LOAD_FEED_RATE  647 
struct  us_tlc_load_feed_rate_m8g„t  { 
int  msgid ; 
double  feed.rate; 

Measurement_units_type  units; 

}; 


•define  US_TLC_LOAD_TRAVERSE_RATE  648 
struct  u8_tlc_load_traver8e_rate_msg_t  { 
int  msgid; 

double  traverse.rate ; 
Heasurement_units_type  units; 

}; 


•define  US_TLC_LOAD_ACCELERATIOI  649 
struct  us_tlc_load_acceleration_msg_t  { 
int  msgid; 
double  accel; 

Measurement.units.type  units; 

}; 


•define  US_TLC_LOAD_JERK  650 
struct  us_tlc_load_jerk_msg_t  { 
int  msgid ; 
double  jerk; 

Measurement_units_type  units ; 

}; 


tolerance 

is  the  blending  algorithm 
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tdefine  US_TLC_LOAD_PROXIHITY  651 
struct  us_tlc_load_proxiinity_in8g_t  { 
int  msgid; 

AxisNask  axis; 
double  distance; 

}; 


tdefine  US_TLC_LOAD_COITACT_FORCES  652 
struct  us_tlc_load_contact_forces_nisg_t  { 
int  msgid; 

TRAISFORM  * tr; 

Representation_units_type  units; 

int  dof ; 

long  cf SelVect ; 

long  cfComplyVect ; 


double  ecfFtSetpoints; 

double  *cfFtGains; 
double  ecfNarFcVel; 

}; 

tdefine  US_TLC_LOAD_JOIIT_LIMIT  653 
struct  us_tlc_load_joint_limit_msg_t  { 
int  msgid; 

AxisNask  axis ; 
double  •jtLimit; 

}; 

tdefine  US_TLC_LOAD_COITACT_FORCE_LIMIT  654 
struct  us_tlc_load_contact_force_limit_msg_t  { 
int  msgid; 

double  *ctFLimit ; //  contact  force  limit 

}; 

tdefine  US_TLC_L0AD_C0ITACT_T0RQUE_LII1IT  655 
struct  u8_tlc_load_contact_torque_limit_msg_t  { 
int  msgid ; 

double  ectTLimit;  //  contact  torque  limit 

}; 

tdefine  US_TLC_LOAD_SEISOR_FUSIOi_POS_LimT  656 
struct  us_tlc_load_8en8or_f U8ion_po8_limit_m8g_t  { 
int  msgid; 

double  efsPLimit;  //  position  limit  for  sensor  based  motion 

}; 

tdefine  US_TLC_LOAD_SEISOR.FUSIOI_ORIEIT_LIMIT  657 
struct  U8_tlc_load_8en8or_fu8ion_orient_limit_msg_t  { 
int  msgid; 

double  *f sOLimit ; //  orientation  limit  for  sensor  based  motion 

}; 

tdefine  US_TLC_LOAD_SEGHEIT_TIME  658 
struct  us_tlc_load_8egment_time_msg_t  { 
int  msgid; 

double  time;  //  duration  of  segment 

}; 


//  transform  from  HERGE  frame 
//  to  FORCE  frame 
II  transform  rep. 

//  degrees  of  freedom 
//  hybrid  selection  vector  for 
//  FORCE  frame 

//  selection  vector  specifying 
//  vhich  position  DOFs  of  FORCE 
//  freune  also  have  compliance 
//  force  setpoints  in  force 
//  controlled  DOFs  of  FORCE  frame 
//  force  gains  in  FORCE  frame 
//  max  velocities  in  DOF  of 
//  force  frame  due  to  force  control 


//  joint  space  limit 


tdefine  US.TLC.LOAD.TERMIIATIOI.COIDITIOI  659 
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struct  us_tlc_load_tennination_condition_msg_t  { 
int  msgid; 


enum  { time.term  = 

0x01, 

time.max  = 

0x02, 

trans_del  = 

0x04, 

ang_del  = 

0x08, 

force.err  = 

0x10, 

torque_err  = 

0x20, 

vel_profile  = 

0x40, 

} condition; 

int  select ; 

double 

testTime ; 

double 

endTime ; 

double 

endTransDel ; 

double 

endAngDel ; 

double 

endTransVel; 

double 

endAngVel ; 

double 

endForceErr; 

double 

endTorqueEff ; 

double 

endForceVel ; 

double 

endTorqueVel ; 

}; 

tdefine  US_TLC_IICR_VELOCITY  660 
struct  us_tlc_incr_velocity_insg_t  { 
int  nsgid; 
int  i ; 

double  increment ; 

}; 

tdefine  US_TLC_IICR_ACCELERATIOI  661 
struct  us_tlc_incr_acceleration_msg_t  { 
int  msgid ; 
int  i ; 

double  increment ; 

}; 


// 

//  Task  Level  Control 

// 

//  Command  Data 

// 

tdefine  US_TLC_SET_G0AL_P0SITI0I  662 
struct  us_tlc_set_goal_position_msg_t  { 
int  msgid ; 
double  *data; 

}; 

tdefine  US_TLC_GOAL_SEGNaT  663 
struct  us_tlc_goal_segment_msg_t  { 
int  msgid; 

SEGHEIT.SELECT  ^segment ; 

}; 

tdefine  US_TLC_ADJUST_AXIS  664 
struct  us_tlc_adjust_axis_msg_t  { 
int  msgid; 

AxisNask  tucis; 
int  i ; 

double  evalue ; 

}; 


//  bit  mask  for  termination  condition 
//  time  over  ehich  to  avg  ending  condition 
//  variables 

//  maximum  ending  motion  time 

//  total  translation  due  to  sensor  based 

//  motion  in  MERGE  frame 

//  total  angular  motion  due  sensor  based  motion 
//  motion  in  MERGE  frame 

//  magnitude  of  rate  of  change  of  endTransDel 
//  magnitude  of  rate  of  change  of  endAngDel 
//  contact  force  error  vector  magnitude 
//  contact  torque  error  vector  magnitude 
//  magnitude  of  raet  of  change  of  endForceErr 
//  magnitude  of  raet  of  change  of  endTorqueErr 


//  l=increment,  -l=decrement , 0=set 
//  if  amount=0,  system  decides 


//  l=increment,  -l=decrement , 0=set 
//if  amount=0,  system  decides 


//  segment  type  A description 


//  l=increment,  -l=decromont , 0=set 
//  if  amount=0,  system  decides 
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//  Status  Data 

fdefine  US_TLC_UPDATE_SEISOR_FUSIOI  665 
struct  us_tlc_update_sensor_f usion.msg.t  { 
int  msgid; 

TRAISFORH  * update; 

}; 


// 

// 

//  TLC: : task  level  control  : cutting/machining 

// 

#dofine  US_TLC_SELECT_PLAIE  666 
struct  us_tlc_8elect_plane_msg_t  { 
int  msgid; 

AxisMask  axis; 

}; 


tdefine  US_TLC_USE_CUTTER_RADIUS_COMPEISATIOI  667 
struct  us_tlc_use_cutter_radius_compensation_msg_t  { 
int  msgid; 
double  radius; 

}; 


•define  US_TLC_START_CUTTER_RADIUS_COMPEISATIOI  668 
struct  us_tlc_8tart_cutter_radiu8_compen8ation_msg_t  { 
int  msgid; 
double  side; 

}; 


•define  US_TLC_STOP_CUTTER_RADIUS.COMPEISATIOI  669 
struct  U8_tlc_8top_cutter_radiu8_compen8ation_m8g_t  { 
int  msgid; 

}; 


•define  US_TLC_STRAIGHT_TRAVERSE  670 
struct  U8_tlc_8traight_traver8e_m8g_t  { 
int  msgid ; 
double  x; 
double  y; 
double  z; 

}; 


•define  US_TLC_ARC_FEED  671 
struct  U8_tlc_arc_feed_m8g_t  { 
int  msgid; 

AxisHask  first.axis; 
AxisMask  second.axis; 
double  rotation; 
double  axis_end_point ; 


•define  US_TLC_STRAIGHT_FEED  672 
struct  us_tlc_8traight_feed_m8g_t  { 
int  msgid ; 
double  x; 
double  y; 
double  z; 

}; 


•define  US_TLC_PARAMETRIC_2D_CURVE_FEED  673 
struct  u8_tlc_parametric_2d_curve_f eed_m8g_t  { 
int  msgid; 

FUICTIOI.PTR  f 1 ; 
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FUICTIOB.PTR  f2; 

double  start.paraneter.value ; 

double  end_paraineter_value ; 


tdefine  US_TLC_PARAMETRIC_3D_CURVE_FEED  674 
struct  us_tlc_parainetric_3d_curve_feed_msg_t  { 
int  msgid; 

FUICTIOI.PTR  xfcn; 

FUICTIOB.PTR  yfcn; 

FUICTIOB.PTR  zfcn; 
double  start.parameter.value ; 
double  end.paraneter.value ; 

}; 


tdefine  US.TLC.BURBS.KIOT. VECTOR  675 
struct  us.tlc.nurbs.knot.vector.msg.t  { 
int  msgid; 

int  i;  //  which  element,  0 = first 

double  k; 

}; 

tdefine  US.TLC.BURBS.COBTROL.POIIT  676 
struct  U8.tlc.nurbs.control.point.msg.t  { 
int  msgid; 

int  i;  //  which  CP,  0 = first 

double  x; 
double  y; 
double  z; 

double  w;  //  the  weight 

}; 

tdefine  US.TLC.BURBS.FEED  677 
struct  us.tlc.nurbs.feed.msg.t  { 
int  msgid; 
double  sStart ; 
double  sEnd; 

}; 


tdefine  US.TLC.TELEOP.FORCE.REFLECTIOB.UPDATE  678 
struct  ns_tlc.teloop.force.refloction.msg_t{ 
int  msgid; 
double  *data; 

}; 


// 


////////////////////////////////////////////////////////////////////////// 

// 

// 

//  LOCAL 

// 

// 

////////////////////////////////////////////////////////////////////////// 


//  *•  DISCLAIMER  II  •• 

// 
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//  The  follosing  LOCAL  interfaces  are  preliminary.  The  LOCAL  interfaces 
//  are  an  initial  attempt  at  providing  a solution.  These  interfaces  have 
//  not  undergone  the  necessary  peer-review  process.  Please  do  not  let  the 
//  preliminary  state  of  these  interfaces  reflect  too  negatively  on  the 
//  overall  state  of  the  UTAP  interfaces.  At  some  point  in  the  future, 

//  these  interfaces  will  undergo  the  scrutiny  of  a review  panel  and  will 
//  receive  the  same  level  of  discussion  and  revision  that  was  given  to 
//  the  LOCAL  interfaces . Comments  concerning  the  LOCAL  interfaces  are 
//  welcome,  and  should  be  directed  to  the  UTAP  interface  coordinator, 

//  listed  on  the  disclaimer  page. 

// 

//  At  some  point  the  feature-based  concepts  of  the  APT  Part  Programming 
//  Language  will  be  explicitly  incorporated  into  the  LOCAL  interfaces, 

//  specifically  the  APT  Tool  Axis  Control  Language,  and  the  APT  Heasure 

//  Language.  APT  contains  hooks  for  Robotics  and  Vision  Commands  (Rules  14xx) . 

// 

II  The  current  emphasis  of  the  LOCAL  definitions  is  to  establish  the 
//  framework  in  which  the  operator  can  make  selections  and  have  these 
//  selections  registered  in  the  control  system. 

n 


// 

//  TDS  - the  task  description  module  commands/controls  task 
•define  TASK.DESCRIPTIOS  1000 


•define  US.TDS.LOAD.USER  1000 
struct  us_tds_load_user_msg_t{ 
int  msgid ; 

USER.TYPE  user; 

}; 


•define  US_TDS_SELECT_PROGRAH  1001 
struct  us_tds_select_program_msg_t{ 
int  msgid; 
char  filename [128] ; 

}; 


•define  US_TDS_EXECUTE_PROGRAM  1002 
struct  us_tds_execute_program_msg_t{ 
int  msgid; 
char  filename [128] ; 

}; 


•define  US_TDS_SELECT_OPERATIOI  1003 
struct  us_tds_select_operation_msg_t{ 
int  msgid; 


_move 

= 

1 , 

_paint 

= 

2, 

.strip 

= 

3, 

.finish 

= 

4, 

.polish 

= 

5, 

.clean 

6. 

.deseal 

= 

7, 

.seal 

= 

8, 

.inspect 

= 

9, 

.cut 

= 

10 

} task; 

}; 


•define  US_TDS_SELECT_OPMODE  1004 
struct  us_tds_select_opmode_msg_t{ 
int  msgid; 
enum  { 

TELEOP , 


//  limit  programming  capabilities 


//  filename  on  disk 


II  filename  on  disk 


//  joystick  motion 
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SUPERVISED, 

AUTOIOHOUS , 

TRADED, 

SHARED 
} type; 

AxisNask  axis; 

}; 

tdefine  US_TDS_LOAD_SELECTIOIS  1005 
struct  us_tds_load_solections_insg_t{ 
int  msgid; 

enum  { select.agent , 
select_io , 
select.object , 
select.traj , 

}selection; 
char  name [128] ; 

}; 

tdefine  US_TDS_LOAD_REFEREBCE_UIITS  1006 
struct  us_tds_load_reference_units_msg_t{ 
int  msgid; 

Heasurement_units_type  units; 

}; 

tdefine  US_TDS_LOAD_RATE_DEFAULTS  1007 
struct  us_tds_load_rates_msg_t{ 
int  msgid; 
enum  { 

8et_def ault_f eed_rate , 
set_default_traver8e_rate , 
8et_ta8k_8pace_acceleration_limit 
} selection; 

enum  { meters, 
inches , 

millimeters  } units; 


//  operator  supervises  actions 
//  controller  makes  crucial  decision 
//  traded  control  of  motion 
//  control  of  axis  of  motion  is  shared 
//  type  of  operator  interaction 


//  per  second 
//  per  second 
//  per  second  per  second 


double  rate; 

}; 


tdefine  US_TDS_LOAD_ORIGII  1008 


struct  us_tds_load_origin_msg_t{ 
int  msgid; 

enum  { device.origin, 

relative.origin, 

zero_device, 

device.vieu, 

} selection; 
char  name  [128] ; 


}; 


tdefine  US_TDS_LOAD_SEISIIG_DEFAULTS  1009 
struct  us_tds_load_sensing_msg_t{ 
int  msgid; 
enum  { 


set.def ault_sensor_limit , 
set_default_8ensor_orientation, 
set_8ensor_limit_override , 
clear_sensor_ override 
} selection; 
char  8ensor_name[128] ; 

Attribute_t  attr; 
double  setting; 


//  use  current  values  of  device 


//  device  name 
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// 

// 

//  TK  - The  current  state  of  the  manipulation,  end-effecting,  and  tooling 
//  systems  is  knosn  and  stored  in  the  task  knosledgebase  and  trajectory 
//  description  modules 

♦define  TASK.KIOULEDGE  1100 

♦define  US_TK_DEFIIE_FRAMEWORK  1101 
struct  U8_task_f ramework.msg.t  { 
int  msgid; 

//  -1  indicates  that  the  user  must  fill  in  the  field 
enum  { .move , 

.paint , 

.strip , 

.finish , 

.polish , 

.clean , 

.deseal , 

.seal , 

.inspect , 

} task; 


int  step.number; 

// 

char  macro. name [128] ; 

// 

USER.TYPE  user; 

// 

//  Select  Operation  Method 
enum  { TELEOP, 

// 

SUPERVISED, 

// 

AUTOIOMOUS , 

// 

TRADED , 

// 

SHARED , 

// 

} type; 

// 

AxisMask  axis; 

int  number.of .agents ; 
char  agent_class[l28] [100] ; 
char  agent_list[128] [100] ; 

// 

char  tool.class [128] ; 

// 

char  tool.name [128] ; 

// 

char  object.class [128] ; 

// 

char  object_n^une[128]  ; 

// 

int  task.units; 

// 

POSITIOI  program. home ; 
POSITIOI  program.origin ; 

POSITIOI  relative.origin; 

TRAISFORN  • base.frame; 
TRAISFORH  • tool.frame; 


TRAISFORH  • zero.axes.force ; 
TRAISFORH  • zero.tool.f orce ; 


int  default. task.reference.units ; 
int  task.reference.units; 


use  step  number  or 
task  macro  name 

minimum  programming  capabilities 

joystick  motion 

operator  supervises  actions 

controller  metkes  crucial  decision 

traded  control  of  motion 

control  of  axis  of  motion  is  shared 

type  of  operator  interaction 


number  of  agents  agents  defaults 


class  of  potential  tools 
default  tool 

attribute  class  of  potential  objects 
use  selects/defines  object 
default  units 
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double  set_task_space_acceleration_limit ; 
double  set_ta8k_space_acceleration_tiine ; 

double  feed_rate; 
double  feed_rate_units ; 

double  traverse.rate ; 
int  traver8e_rate_units ; 

double  default_force_8etting; 
double  guarded_proximity_8etting; 
double  vi8C08ity_setting; 
double  humidity.setting; 
double  desired.temperature ; 
double  temperature.limit ; 
double  noiee.limit ; 

}; 


//  def ine8  franevork 
//  definea  atepsiae  actiona 


tdefine  US_TK_MACRO_CREATE  1102 
tdefine  US_TK_NACRO_DELETE  1103 
•define  US_TK_HACRO_MODIFY  1104 
atruct  u8_tk_inacro_m8g_t  { 
int  magid; 

char  frameuork.f ile  [128] ; 
char  action_file  [128] ; 
char  plan [128] ; 

}; 


// 

//  FTPS /TPS 

•define  PAREIT.TASK.PROGRAN.SEQUEICIIG  1300 

•define  US.PTPS.SELECT.AGEIT  1301 
atruct  U8_8elect_re80urce_m8g_t  { 
int  magid; 

TASK.ID  tid; 

RESOURCE.SELECT  agent ; 

SOBUSYSTEM.ID  aaid; 
enum  { SOLO, 

LH, 

RH, 

} type; 

}; 


•define  US_TPS_SELECT_TOOL  1302 
atruct  U8_8elect_tool_m8g_t  { 
int  magid ; 

TASK.ID  tid; 

EID.EFFECTOR.SELECT  tool; 
SUBUSYSTEM.ID  aaid; 


•define  US_PTPS_SELECT_SEISOR  1303 
atruct  u8_8elect_8en8or_m8g_t  { 
int  magid ; 

TASK.ID  tid; 

RESOURCE. SELECT  agent; 
SUBUSYSTEM.ID  aaid; 
enum  { SOLO , 

LH, 

RH, 

} type; 
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}; 


tdofine  US_PTPS_IITERP_RUI_PLAI  1303 
struct  us_interp_run_plan_msg_t  { 
int  msgid; 

SUBUSYSTEH.ID  ssid; 


enum  { UTAP 

= 1, 

RS274D 

= 2, 

SIL 

= 3, 

GSL 

= 4, 

} type  ; 

char  pl^m[128] 

; 

}; 

tdefine  US.PTPS. 

IITERP.HALT.PLAI  1304 

struct  us_interp_halt_plan_insg_t  { 
int  msgid; 

SUBUSYSTEH.ID  ssid; 


}; 


tdefine  US.PTPS.IIPUT.REQUEST  1305 
struct  us.ptps.input.request.msg.t  { 
int  msgid; 

SUBUSYSTEH.ID  ssblocker; 
SUBUSYSTEH.ID  ssenabler; 


peer.ack 

= 1 

peer.done 

= 2 

shared. resource 

= 3 

type; 

tdefine  US.PTPS.OUTPUT.EIABLE.SUBSYSTEH  1306 
struct  us.ptps. output. enable.msg.t  { 
int  msgid; 

SUBUSYSTEH.ID  ssblocker; 

SUBUSYSTEH.ID  ssenabler; 
enum  { peer.ack  = 1 , 

peer.done  = 2, 

shared. resource  = 3, 

} type; 

}; 

// 

//  TPS 

tdefine  TASE.PROGRAH.SEQUEICIIG  1400 


tdefine  US.TPS.FREESPACE.HOTIOI  1401 
struct  us.tps.freespace.msg.t  { 
int  msgid; 

}; 


tdefine  US.TPS.GUARDED.HOTIOB  1402 
struct  us.tps.guardede.msg.t  { 
int  msgid; 

}; 


tdefine  US.TPS.COITACT.HOTIOI  1403 
struct  us.tps.constact.msg.t  { 
int  msgid; 

}; 


tdefine  US.TPS.SET.SUPERVISORY.HODE  1404 
struct  us. supervisory .mode.msg.t  { 
int  msgid; 
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//  need  hybrid  parameter  stuff  here 

}; 


fdefine  US_TPS_SELECT_FEATURE  1405 
struct  us_6elect_feature_msg_t  { 
int  msgid; 

FEATURE  surface ; 

double  fx.fy.fz;  //  eorld  to  feature  origin  translation 

double  fol,fo2,fo3;  //  sorld  to  feature  origin  rotation 

}; 

fdefine  US_TPS_SELECT_MATERIAL  1406 
struct  us_8elect_material_msg_t  { 
int  msgid; 

MATERIAL.TYPE  m; 
double  maxx ,maxy ,maxz ; 
double  minx,miny ,minz; 
double  fol,fo2,fo3; 
double  strength; 
double  minforce; 
double  maxforce; 

}; 

fdefine  US_LOAD_OBSTACLE  1407 
struct  us_load_obstacle_msg_t  { 
int  msgid; 

FEATURE  obstacle; 

}; 

fdefine  US_LOAD_PATTERI  1408 
struct  us_load_pattern_msg_t  { 
int  msgid; 

GEOHETRY.PATTERI  pattern; 

}; 

fdefine  US_TPS_MARK.EVEIT  1409 
struct  us_tps_mark_event_msg_t  { 
int  msgid ; 
enum  { 

peer.signal  = 1, 

//  coordinate  devices/io/sensed  motion 
} event ; 

}; 


//  type  of  material 

//  feature  to  operation  max  translation 
//  feature  to  operation  min  translation 
//  feature  to  operation  max  rotation 
//  maximum  material  strength 
//  min  amount  of  surface  contact? 

//  max  amount  of  surface  contact? 


fdefine  US_TPS_EIABLE  1410 
struct  us_ptp8_enable_msg_t  { 
int  msgid; 

enum  { peer.msg  = 1 , 

shared.resource  = 2, 

}enable ; 

}; 


// 

//  01  - Operator  Interface  Messages 

fdefine  OPERATOR. I ITERF ACE  1500 

fdefine  US.BEGIl.FRANEUORE  1501 
fdefine  US.EID.FRAMEWORK  1502 
fdefine  US.CREATE.FRAMEMORK  1503 
fdefine  US.DELETE.FRAHEWORK  1504 
struct  us_frameBork_msg_t{ 
int  msgid; 
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char  name  [128]  ; 

}; 

#define  US_ADD_SYMBOLIC_ITEM  1505 
tdefine  US_DELETE_SYMBOLIC_ITEH  1506 
struct  us_syinbolic_itein_msg_t{ 
int  msgid ; 
char  name  [128] ; 

}; 

tdefine  US_ADD_SYMBOLIC_ITEH_ATTR  1507 
tdefine  US_DELETE_SYMBOLIC_ITEM_ATTR  1508 
tdefine  US_SET_SYMBOLIC_ITEM_ATTR  1509 
struct  us_8ymbolic_item_attribute_m8g_t{ 
int  msgid; 
char  name  [128]  ; 
char  attribute_name[128] ; 

int  size;  //  e.g.  number  of  joints 

int  xdim; 
int  ydim; 

Representation.units.type  rep; 

Measurement.units.type  units; 

generic_value_a  values;  //  context-dependent  values 


}; 


// 

//  ON  - object  modeling  module 
tdefine  OBJECT.NODELIIG  1600 


tdefine  US.OM.CREATE  1601 
struct  us_om_croato_m8g_t  { 
int  msgid ; 

enum  { device_origin  = 1, 

relative_origin  = 2, 
zoro_device  = 3, 
device_viev  = 4, 
vorkarea  = 5 , 
target  = 6 , 
obstacle  = 7 , 

} type; 


}; 


char  name  [128] ; 

//  Reference  Frame  - e.g.,  given  in  VDT  relative  coordinates 
char  device [128];  //  use  name  for  nos 

GEONETRY  data;  //  define  shape 


tdefine  US_ON_DELETE  1602 
struct  us_om_delete_msg_t  { 
int  msgid ; 

enum  { device.origin  = 1 , 

relative.origin  = 2, 
zero_device  = 3, 
device_vies  = 4, 
sorkarea  = 5 , 
target  = 6, 
obstacle  = 7, 

} type; 

char  name  [128] ; 

}; 


tdefine  US_0M_M0DIFY  1603 
struct  u8_om_modify_msg_t  { 
int  msgid; 
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enun  { device.origin  = 1 , 

relative.origin  = 2, 
zero_device  = 3, 
device.vieo  = 4, 
vorkarea  = 5 , 
target  = 6, 
obstacle  = 7 , 

}type; 


char  name  [128] ; 

//  Reference  Frame  - 
char  device [128]; 
GEOMETRY  data; 


e.g.,  given  in  VDT  relative  coordinates 

//  use  name  for  nos 
//  define  shape 


}; 


// 

//  OC  - The  object  calibration  module  provides  the  operator  with  a means 
//  of  updating  knosledge  on  the  object(s)  positions  and  orientations 
fdefine  OBJECT.CALIBRATIOI  1700 

•define  US_OC_SET_CALIB  1701 
•define  US_OC_GET_CALIB  1702 
struct  us_oc_calib_msg_t  { 
int  msgid ; 

enum  { device.origin  = 1 , 

relative_origin  = 2, 

2ero_device  = 3, 
device.vies  = 4, 
sorkarea  = 5 , 
target  = 6, 
obstacle  = 7, 

}type ; 

char  name  [128] ; 

//  Reference  Frame 
char  device  [128]; 

GEOMETRY  data; 

}; 

•define  US_OC_SET_ATTR  1703 
struct  us_oc_set_attr_msg_t  { 
int  msgid ; 

char  name  [128];  //  device  name 

Modifier_t  modifier; 

Attribute.t  attributes; 
int  size; 

Representation_units_type  rep; 

Measurement_units_type  units ; 
generic_value_a  value ; 

}; 


- e.g.,  given  in  VDT  relative  coordinates 

//  use  name  for  nos 
//  define  shape 


•define  US_OC_GET_ATTR  1704 
struct  us_oc_get_attr_msg_t  { 
int  msgid; 

char  name  [128] ; //  device  name 

Modifier_t  modifier; 

Attribute_t  attributes; 

}; 


// 

//  OK  Input 

•define  OBJECT.KIOULEOGE  1800 

•define  US_0K_REC0RD  1801 
•define  US_OK_PLAYBACK  1802 
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struct  u8_ok_record_m8g_t  { 
int  msgid; 
char  narae  [128] ; 

}; 

•define  US_0K_CREATE_0BJ  1803 
struct  us_ok_create_m8g_t  { 
int  msgid; 
char  name  [128] ; 

OBJECT  Ob; 

}; 

•define  US_0K_DELETE_0BJ  1804 
struct  us_ok_delete_msg_t  { 
int  msgid; 
char  name  [128] ; 

}; 

•define  US_0K_H0DIFY  1805 
struct  us_ok_modify_m8g_t  { 
int  msgid; 
int  obj_id; 
int  size; 
void  * data; 

}; 


•define  US_OK_HODIFY_ATTRIBUTE  1806 
struct  us_ok_modify_attribute_msg_t  { 
int  msgid; 
int  obj_id; 

Attribute_t  attr; 
int  size; 
void  * data; 

}; 


•define  US_OK_ATTRIBUTE_QUERY  1807 
struct  us_ok_attr_query_msg_t  { 
int  msgid ; 
int  obj_id; 

Attribute_t  attr; 

}; 


//  Output 

•define  US_OK_OUTPUT_REGISTERED_OBJ_ID  1808 
struct  U8_regi8tered_id_msg_t  { 
int  msgid; 
char  name  [128] ; 
int  obj_id; 

}; 


•define  US_OK_ATTRIBUTE_RESPOISE  1809 
struct  us_ok_attr_respon8e_msg_t  { 
int  msgid; 
int  obj_id; 

Attribute_t  attr; 
double  evalues ; 

}; 

// 

//  TRD  - the  trajectory  description  module  suports  the  creation, 
//  deletion  or  modification  of  a trajectory 
•define  TRAJECTORY.DESCRIPTIOI  1200 

•define  US.TRD.OPEI  1200 
struct  u8_trd_open_msg_t{ 
int  msgid; 
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ch&r  narae[128] ; 
enuin  { create  = 1 , 
append  = 2 , 
readonly  = 3, 
} type; 

}; 


•define  US_TRD_ERASE  1201 
•define  US_TRD_RECORD  1202 
•define  US_TRD_REC0RD_0i  1203 
•define  US_TRD_RECORD_OFF  1204 
struct  U8_trd_record_msg_t{ 
int  msgid; 
char  nane[128] ; 

}; 


•define  US.TRD.FIID  1205 
•define  US_TRD_IEXT  1206 
•define  US_TRD_PREVIOUS  1207 
•define  US.TRD.DELETE  1208 
struct  us_trd_positioning_msg_t{ 
int  msgid; 
char  name [128]; 

int  num.element;  //  ~1 

}; 


•define  US.TRD.IAHE.ITEM  1209 
struct  U8_trd_name_item_msg_t{ 
int  msgid; 
char  name [128]; 

}; 


•define  US_TRD_DELETE_ITEM  1210 
struct  U8_trd_dolete_item_m8g_t{ 
int  msgid; 
int  id ; 

}; 


•define  US_TRD_SET_JOIIT_I!ODE  1211 
struct  us_trd_set_ joint _mode_msg_t{ 
int  msgid; 
double  dof ; 

}; 


•define  US_TRD_SET_CARTESIAI_MODE  1212 
struct  us_trd_8et_Cartosian_mode_msg_t{ 
int  msgid; 
double  dof ; 

}; 


•define  US_TRD_HODIFY  1213 
struct  us_trd_modify_msg_t{ 
int  msgid ; 
char  name [128] ; 
int  num.element ; 
double  edata; 

}; 


•define  US_TRD_ADD_ELEHEIT  1214 
struct  us_trd_add_element_m8g_t{ 
int  msgid; 
double  *data; 

}; 


= current 
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// 

//  SGD  I ADS  - Analysis  and  Device  Simulator  Modules.  These  modules  serve 
//  a dual  purpose:  1)  operator  can  call  the  analysis  menu,  etner  state 
//  data  eoid  end  point  data,  and  let  the  simulator  establish  the 
//  appropriate  trajectory/path  through  teleoperation  of  the  simulation 
//  2)  analyzes  the  exeuction  of  the  system  tabs  sequence  by  examining 
//  the  curernt  state  of  teh  system  against  predetermined  constraints. 

//  SS  - subsystem  simulator 

//  SGD  uses  the  same  messaging  as  the  01 

//  ADS  uses  the  same  messaging  as  the  SGD,  01 
•define  STATUS.GRAPHICS.DISPLAY  1900 
•define  AIALYSIS.DIAGIOSIS.SYSTEH  2000 

•define  US.ADS.COLLISIOI.DETECTED  2001 
struct  us_sgd_error_msg_t  { 
int  msgid; 
char  name  [128]  ; 
int  obj_idl; 
int  obj_id2; 

double  x,y,z;  II  collision.spot 

}; 


// 

// 

//  SS  uses  the  same  messaging  as  the  module  it  is  simulating  but  replace 
//  a SS  for  the  module  name. 

•define  SUBSYSTEM.SIHULATIOI  2100 


•end if 


H.4  Interface  API  Source 

•ifndef  UTAP_IITERFACE_DEFIIITIOIS 
•include  "generic.defs .h" 

•include  “utap_info_model .h" 

•include  “utap_data_defs .h" 

•include  “undefined.types.h" 

/•* 

This  header  file  defines  the  interfaces  for  communication  betseen 
modules  in  the  Generic  C5  Architecture. 

Generic  Telerobotic  Architecture  for  C-5  Industrial  Processes 
contains  modules  of  which  the  following  have  acronyms: 

NODULES  lANIIG/ACROIYNGS : 

REMOTE : 

RSC  - robot  servo  control 

TOOL  - tool  control 

SEISOR-  sensor  control 
PIO  - programmable  io 

TLC  - task  level  control 

CLC  - closed  loop  control 

DB  - data  base  is  part  of  TLC  A CLC 
VS  - virtual  sensor 
LOCAL: 

TDS  - task  description  and  supervision 

TK  - task  knowledge 

TED  - trajectory  description 

PTPS  - parent  task  program  sequencer 

TPS  - task  program  sequencer 

01  - operator  interface 
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OK  - object  knoBledge 

OC  - object  calibration 

ON  - object  modeling 

SGD  - status  graphics  displays 

SS  - subsystem  simulators 

ADS  - analysis  and  diagnosis 

♦/ 

/•* 

A little  table  of  contents: 


GEIERIC: 

101 

- 

199 

ERROR: 

-100 

- 

-200 

R0B0T_SERV0 : 

200 

- 

299 

TOOL: 

300 

- 

399 

SEISOR: 

400 

- 

499 

PIO: 

500 

- 

599 

TLC: 

600 

- 

699 

DB: 

700 

- 

799 

VS: 

800 

- 

899 

TDS: 

1000 

- 

1099 

TK: 

1100 

- 

1199 

TRD: 

1200 

- 

1299 

FTPS: 

1300 

- 

1399 

TPS: 

1400 

- 

1499 

01: 

1500 

- 

1599 

OK 

1600 

- 

1699 

OC 

1700 

- 

1799 

OH 

1800 

- 

1899 

SGD: 

1900 

- 

1999 

ADS: 

2000 

- 

2099 

SS: 

*/ 

2100 

- 

2199 

us.startupO ; 
us.shutdounO  ; 
us_reset(  int  type, 

long  mask) ; 
us_enable(  int  axis); 
us_disable(  int  axis); 
us_estop() ; 
us_start() ; 
us_stop() ; 
us_abort() ; 
us.haltO  ; 
us_init() ; 
us_hold() ; 
us_pause() ; 
us.resumeO ; 
us_zero(  long  mask); 
us_begin_single_step() ; 
us_next_single_step() ; 
us_clear_single_step() ; 
us_begin_block() ; 
us_ond_block() ; 

us_begin_pl«m(  char  naffle[128]); 
us_end_plan() ; 
us_use_plan() ; 

u8_begin_macro(  char  name [128]); 
us_end_macro() ; 

us_execute_macro(  char  name[128]); 
us_begin_event(  char  name [128], 
int  type , 

TIME  t); 

us_end_event ( ) ; 
us_mark_breakpoint() ; 
us_mark_event(  char  name[128]); 
us_get_selection_id(  char  name [128]); 
us_post_selection_id() ; 
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us_use_selection() ; 
us_use_axi8_nask(  AxisNask  axis); 
u8_u8e_ext_algorithm(  int  slot); 
us_load_ext_parameter(  int  slot); 
us_get_ext_data_value(  int  slot, 

ROUTE  r) ; 

us_po8t_ext_data_value(  int  slot, 

void  * data) ; 

us_8ot_oxt_data_value(  int  slot, 

void  * data) ; 

us_load_8tatU8(  int  type) ; 
us_load_status_period(  double  time); 
us_generic_status_report_t ( STATUS.TYPE  status, 

double  progress , 
int  type, 
int  explanation, 
void  * command.echo) ; 
us_error_command_not_implomented( ) ; 

U8_error_command_ontry(  int  f ield.num) ; 
us_error_duplicate_name() ; 
us_orror_command_bad_data(  int  f ield.num) ; 
us_orror_no_data_availablo(  int  field.num) ; 
us_error_saf ety_violation(  int  field_num) ; 
us_error_limit_excoeded(  Attribute_t  attr) ; 
us_error_over_specifiod(  int  axis.number) ; 
us_error_under_specif iedO ; 
us_axis_8orvo_use_angle_units() ; 
us_axis_sarvo_u8e_radian_unit8() ; 
us_axis_8ervo_U8e_abs_po8ition_mode() ; 
us_axis_servo_U8e_rel_po8ition_mode() ; 
us_axi8_8ervo_u8e_ab8_velocity_mode() ; 
us_axi8_8ervo_use_rel_velocity_mode() ; 
u8_axis_8ervo_u8e_pid(  int  joint.mask) ; 
u8_axi8_8ervo_u8e_ff () ; 
us_axi8_servo_use_current() ; 

U8_axi8_8ervo_U8e_voltage() ; 
us_axi8_servo_u8e_8tiffne88(  int  spSelVect, 

double  • gains , 
double  • spNaxVel); 
us_axi8_8ervo_use_compliance() ; 
us_axis_8ervo_u8e_iinpedance() ; 
u8_axi8_servo_8tart_gravity_compensation() ; 
us_axi8_8ervo_8top_gravity_corapen8ation() ; 
U8_axis_8ervo_load_dof ( int  dof); 
us_axi8_servo_load_cycle_time(  double  time); 
u8_axis_8ervo_load_pid_gain(  int  joint .mask, 

double  *p, 
double  *i, 
double  *d) ; 

us_axis_8ervo_load_joint_limit ( int  axis.bit.mask , 

double  ejmaxLimit, 
double  ejminLimit) ; 

U8_axi8_8ervo_load_velocity_limit(  int  axis.bit.mask , 

double  ejvelLimit); 

u8_axis_8ervo_load_joint_gain_limit ( double  ejaGain) ; 
us_axis_8ervo_load_dainping_ values ( double  ejaOamp) ; 
us_axis_8ervo_home(  int  uis)  ; 
us_axis_servo_8et_brake8(  int  axis_bit_mask) ; 
us_axis_8ervo_clear_brakes(  int  axis_bit_mask) ; 
us_axis_8ervo_8et_torques(  int  axis.bit.mask , 

double  * joint.torques) ; 

u8_axis_8ervo_8et_current(  double  • joint.currents) ; 
U8_axis_8ervo_set_voltage(  double  • joint.voltages) ; 
u8_axis_8ervo_8et_po8ition(  double  ejoint.position) ; 
U8_axi8_8ervo_set_velocity ( double  • joint.velocity) ; 
u8_axi8_8ervo_8et_acceleration(  double  • joint.acceleration) ; 
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u8_axi8_8ervo_80t_force(  double  * joint_force) ; 
u8_axi8_8ervo_jog(  int  axi8, 

double  8peed) ; 

us_axi8_8ervo_jog_8top(  int  axis); 
us_8pindle_retract_traver8e() ; 
us_load_8pindle_8peed(  double  r) ; 
us_8tart_8pindle(  int  direction); 
us_8top_8pindle_turning() ; 
us_8pindle_retract() ; 

us_orient_spindle(  double  orientation, 
double  direction); 
u8_lock_spindle_z() ; 
us_use_spindle_force() ; 
us_use_no_spindle_force() ; 
us_floB_8tart_mist() ; 
u8_floB_8top_mi8t() ; 
us_floB_start_flood() ; 
us_floH_8top_flood() ; 
us_floH_load_paraineter8(  int  paran, 

double  value.rate, 
int  flow, 
int  action) ; 

u8_8tart_transfonn() ; 
u8_8top_transform( ) ; 
us_8tart_filtor() ; 
us_stop_filter() ; 

us_8en8or_u8e_mea8urement_unit8(  (!easuroment_unit8_type  array_unit8) ; 
U8_8ensor_load_sainpling_8peed(  double  value); 
us_8en8or_load_frequency(  double  value); 
u8_8en8or_load_tran8fonii(  double  x, 

y. 

z> 

el , 
e2, 
e3)  ; 

u8_8en8or_load_f ilterC  int  type, 

double  f ilter_frequency) ; 
U8_8en80r_get_reading(  ROUTE  r) ; 

U8_8en80r_get_attribute8_reading(  ROUTE  r, 

Attribute_t  attr) ; 

u8_voctor_8en8or_get_reading(  ROUTE  r) ; 
u8_ft_sen8or_po8t„reading(  int  health, 

double  ef, 
double  *t) ; 

u8_8calar_8en8or_po8t_reading(  double  upper.limit , 

double  lover_limit) ; 

us_VECT0R_8en8or_post_reading(  double  evector) ; 
U8_2D_8en8or_load_array_pattern(  long  array.pattern , 

float  period) ; 

us_2D_8on8or_U8o_array_typo(  int  typo); 
u8_2D_8on8or_got_roading(  ROUTE  r, 

Nodif ier_t  mod) ; 

us_2D_sensor_po8t_reading(  int  rose, 

int  col8, 

double  •array_values) ; 
U8_image_sen80r_u8e_f rame_grab_mode ( ) ; 
u8_image_8en8or_u8e_hi8togram_mode() ; 
u8_image_8en8or_u8e_centroid_mode() ; 
u8_image_8en8or_u8e_gray_level_mode ( ) ; 

u8_image_8ensor_use_threshold_mode(  double  ethreehold) ; 
us_image_8ensor_compute_8patial_derivatives() ; 
us_image_8en8or_compute_tomporal_derivatives() ; 
u8_image_8ensor_u8e„8egmentat ion.mode ( ) ; 

u8_image_8en8or_u8e_recognition_mode(  OBJECT  to.recognize) ; 
u8_image_8en8or_compute_range_mode() ; 
u8_image_8en8or_cofflpute_f loB.mode ( ) ; 
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us_image_8en8or_calibration(  int  calibration.state , 

int  cur8or_value , 

float  cx, 

float  cy, 

float  ex, 

float  ncx, 

float  nfx, 

float  dx , 

float  dy , 

float  dxp, 

float  focal.length , 

float  diatort ) ; 

us_image_8et_8ensor_position(  float  x, 

float  y, 
float  z, 
float  pan, 
float  tilt , 
float  zoom) ; 

u8_image_adjust_position(  int  axis, 

int  i , 

double  *¥8106); 

us_image_adjust_focu8(  int  i, 

double  increment); 

us_image_po8t_8pecification(  STATUS_TYPE  status, 

int  num_of .cameras , 

' int  calibration.state , 

int  xpixels, 
int  ypixels, 
int  type, 

TRAISFORH  * base) ; 

us_image_post_pixel_map_reading(  STATUS.TYPE  status, 

TINE  timestamp, 
int  num.cameras, 
int  rous , 
int  cols, 
int  *image_data) ; 

us_image_post_histogram_reading(  STATUS.TYPE  status, 

TINE  timestamp, 
int  num.cameras, 
int  roBs , 
int  cols, 
int  *image_data) ; 

u8_image_post_xy_char_reading(  STATUS.TYPE  status, 

TINE  timestamp, 
int  num.cameras , 
int  rows , 
int  cols, 
int  *image_data) ; 

u8_image_po8t_byte_symbolic_reading(  STATUS.TYPE  status, 

TINE  timestamp, 
int  num.cameras, 
int  rows , 
int  cols, 
int  *image_data) ; 

u8_image_po8t_thre8hold_reading(  STATUS.TYPE  status, 

TINE  timestamp, 
int  num.cameras, 
int  roBS, 
int  cols, 
int  *image.data) ; 

us. image. po8t_spatial_derivative.reading(  STATUS. TYPE  status, 

TINE  timestamp, 
int  num.cameras , 
int  roBS , 
int  cols, 
int  *image_data) ; 
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us_iiiiage_post_temporal_derivative_reading(  STATUS_TYPE  status, 

TINE  timestamp, 
int  nuffl.cameras , 
int  rows, 
int  cols, 
int  eimage.data) ; 

us_imago_post_recognition_roading(  STATUS.TYPE  status, 

TINE  timest^unp, 
int  num.ceuneras, 
int  rows , 
int  cols, 
int  *image_data) ; 

us_image_post_range_reading(  STATUS_TYPE  status, 

TINE  timestamp, 
int  num.ceuneras , 
int  roes, 
int  cols, 
int  *image_data) ; 

us_image_post_floB_reading(  STATUS_TYPE  status, 

TINE  timestamp, 
int  num.camereis , 
int  rows , 
int  cols , 
int  eimage.data) ; 

us_pio_enable(  int  channel); 
us_pio_disable(  int  channel); 
us_pio_set_mode(  int  direction); 
us_pio_control_Brite(  int  info, 

int  bits.data, 
int  run , 
int  ref  ) ; 

us_pio_scale(  int  channel, 
double  m , 
double  b) ; 

us_pio_data_®rite(  int  type, 

union(  double  dvalue , 
int  ivalue); 


); 

U8_pio_data_read(  int  type, 

int  channel) ; 

us_pio_bit_read(  int  channel.num, 
int  bit) ; 

us_pio_bit_set(  int  channel_num, 
int  bit) ; 

us_pio_toggle_bit(  int  channel.num, 
int  bit) ; 

us_pio_input_data(  int  type, 

union(  unsigned  long  data.register , 
double  value) ; 
unsigned  long  data_mask) ; 
us_tlc_u8e_joint_referonce_framo() ; 
us_tlc_use_Cartesian_referonce_f rameO ; 

us_tlc_use_representation_units(  Neasurement_units_type  units); 
us_tlc_use_absolute_positioning_mode() ; 
u8_tlc_relative_positioning() ; 
us_tlc_use_srist_positioning() ; 
us_tlc_use_tool_positioning() ; 
us_chemge_tool(  int  i) ; 

us_tlc_use_modif ied_tool_length_off 8et8(  int  r); 
u8_tlc_use_normal_tool_length_offsets() ; 
us_tlc_u8e_no_tool_length_offset8() ; 
U8_tlc_use_kinematic_ring() ; 
us_tlc_start_manual_motion(  AxisNask  axis); 
us_tlc_stop_manual_motion(  AxisNask  axis); 
us_tlc_start_automatic_motion(  AxisNask  axis); 
us_tlc_stop_automatic motionC  AxisNask  axis) ; 
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U8_tlc_start_traver8e_inotion()  ; 

U8_tlc_8top_traver8e_motion() ; 
us_tlc_8tart_guarded_motion() ; 
us_tlc_8top_guarded_motion( ) ; 
us_tlc_start_compliant(  AxisNa8k  axis, 

double  *spring) ; 

us_tlc_8top_conipliant ( AxisHask  axis); 
us_tlc_start_fine(  AxisHask  axis, 

double  errtolerance , 
int  proximity) ; 

us_tlc_stop_f ine ( AxisHask  axis); 
us_tlc_start_move_until ( AxisHask  axis, 

double  *contact_forces) ; 
us_tlc_8top_move_until(  AxisHask  axis); 
us_tlc_start_8tandoff ( AxisHask  axis, 

double  *distance) ; 

us_tlc_stop_standoff ( AxisHask  axis)  ; 
us_tlc_8tart_force_positioning() ; 
us_tlc_stop_force_positioning( ) ; 
us_tlc_use_dof ( int  dof ) ; 
us_load_cycle_time(  double  time); 

us_tlc_load_representation_unit8(  Heasurement_units_type  units); 
us_tlc_load_length_units(  Heasurement_units_type  units); 
us_tlc_load_relative_po8itioning(  TRAISFORH  * t); 
us_tlc_2ero_relative_positioning( ) ; 
us_tlc_zerot_program_origin(  TRAISFORH  * t); 
us_tlc_load_kinematic_ring(  Heasurement.units.type  units, 

int  mask)  ; 

us_tlc_load_base_parameter8(  TRAISFORH  * trBase); 
us_tlc_load_tool_parameter8(  char  name[128], 

double  dx, 

dy. 

dz , 

double  ux, 

uy. 

uz , 

double  normal.threshold , 
double  tangential.threshold, 
ORIEITATIOI.TYPE  heading) ; 
us_tlc_load_object(  OBJECT  obj_id, 

TRAISFORH  • t); 

us_tlc_load_object_ba8e(  TRAISFORH  * t); 
us_tlc_load_object_off8et(  int  i, 

TRAISFORH  • t) ; 

us_tlc_load_delta(  int  delta, 

double  magnitude, 
double  frequency) ; 
us_tlc_load_obstacle_volume(  int  i, 

TRAISFORH  • t ) ; 

us_tlc_load_blending(  double  dist , 

BLEID.TYPE  blend) ; 
u8_tlc_load_feed_rate(  double  feed.rate, 

Heasurement_units_type  units); 
us_tlc_load_traverse_rate(  double  traverse.rate , 

Heasurement_units_type  units); 
us_tlc_load_acceleration(  double  accel, 

Heasurement.units.type  units) ; 
us_tlc_load_jork(  double  jerk, 

Heasurement_units_type  units) ; 
us_tlc_load_proximity ( AxisHask  axis, 

double  distance); 

us_tlc_load_contact_f orces(  TRAISFORH  * tr, 

Representation.units.type  units, 
int  dof, 
long  cfSelVect, 
long  cfComplyVect , 
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double  *cfFtSetpoints , 
double  ecfFtCains, 
double  ecfMaxFcVel) ; 
us_tlc_load_joint_limit(  AxisHask  axis, 

double  ^jtLimit); 

us_tlc_load_contact_force_liinit(  double  •ctFLimit); 
us_tlc_load_contact_torque_liinit ( double  •ctTLimit); 
us_tlc_load_8en8or_fusion_pos_liiait ( double  •fsPLimit) ; 
us_tlc_load_8ensor_fusion_orient_limit(  double  ♦fsOLimlt) ; 
us_tlc_load_8eginent_tiine(  double  time); 
us_tlc_load_termination_condition(  int  condition, 

int  select , 
double  testTime, 
double  endTime, 
double  endTransDel, 
double  endAngDel , 
double  endTransVel, 
double  endAngVel, 
double  endForceErr, 
double  endTorqueEff , 
double  endForceVel, 
double  endTorqueVel) ; 

us„tlc_incr_velocity(  int  i, 

double  increment); 
u8_tlc_incr_acceleration(  int  i, 

double  increment) ; 

u8_tlc_8et_goal_position(  double  edata) ; 
us_tlc_goal_segment(  SEGNEIT.SELECT  esegment) ; 
us_tlc_adjust_axis(  AxisHask  axis, 
int  i , 

double  evalue); 

us_tlc_update_sensor„fusion(  TRAISFORH  * update); 
us_tlc_select_plane(  AxisHask  axis); 
us_tlc_use_cutter_radiu8_compen8ation(  double  radius); 
us_tlc_start_cutter_radiu8_compensation(  double  side); 
us_tlc_stop_cutter_radius_compensation() ; 
us_tlc_8traight_traver8e(  double  x, 

double  y, 
double  z) ; 

us_tlc_arc_feed(  AxisHask  first.axis, 

AxisHask  second.axis, 
double  rotation, 
double  axis.end.point) ; 
us_tlc_straight_feed(  double  x, 
double  y, 
double  z) ; 

us_tlc_parametric_2d_curve_feed(  FU1CTI0I_PTR  f 1 , 

FUICTIOI.PTR  f2, 
double  start.parameter.value, 
double  end_parameter_value) ; 
us_tlc_parametric_3d_curve_feed(  FUICTIOI_PTR  xfcn, 

FUlCTIOR.PTR  yfcn, 
FUICTIOI.PTR  zfcn, 
double  start.parameter.value , 
double  end.parameter. value) ; 

us_tlc_nurbs_knot_voctor(  int  i, 

double  k) ; 

U8_tlc_nurbs_control_point(  int  i, 

double  X , 
double  y, 
double  z , 
double  s) ; 

us.tlc.nurbs.feedC  double  sStart, 
double  sEnd); 

us_tlc_teleop_force_reflection(  double  «data) ; 
us.tds.load.userC  USER.TYPE  user) ; 
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us_td8_8elect_progr«m(  char  filename  [128] ) ; 

U8_td8_execute_program(  char  filename [128] ) ; 

U8_td8_8elect_operation(  int  task)  ; 

us_td8_8elect_opmode(  int  type, 

AxisHask  axis) ; 

us_tds_load_8election8(  int  selection, 

char  name  [128] ) ; 

us_tds_load_reference_units(  Measurement.units.type  units); 

us_tds_load_rates(  int  selection, 
int  units, 
double  rate) ; 

us_tds_load_origin(  int  selection, 

char  name  [128] ) ; 

us_tds_load_sensing(  int  selection, 

char  sensor.name [128] , 

Attribute.t  attr, 
double  setting) ; 

us_task_f ramevork(  int  task, 

int  step.number, 
char  macro_name[l28] , 

USER.TYPE  user, 
int  type, 

AxisHask  axis , 
int  number.of .agents , 
char  agent_class[128] [100] , 
char  agent.list [128] [100] , 
char  tool_clas8[128] , 
char  tool_name[128] , 
char  object_clas8[128] , 
char  object_name[128] , 
int  task.units, 

POSITIOI  program.home , 

POSITIOI  program.origin, 

POSITIOI  relative.origin , 

TRAISFORH  * base.f rame , 

TRAISFORN  * tool.frame, 

TRAISFORH  * zero.axes.force , 

TRAISFORH  * zero_tool_force , 

int  def ault_task_reference_units , 

int  task.reference.units , 

double  set.task.space.acceleration.limit , 

double  set_task_space_acceleration_time , 

double  feed.rate, 

double  feed.rate.units , 

double  traverse.rate , 

int  traverse.rate.units , 

double  default.force.setting, 

double  guarded.proximity.setting, 

double  viscosity.setting, 

double  humidity.setting, 

double  desired.temperature , 

double  temperature.limit , 

double  noise.limit) ; 

u8_tk_macro(  char  framework.f ile  [128] , 
char  action.file  [128] , 
char  plan [128] ) ; 

us_8elect_resource(  TASK.ID  tid, 

RESOURCE.SELECT  agent, 

SUBUSYSTEH.ID  ssid, 
int  type) ; 

us_select_tool(  TASK.ID  tid, 

EID_EFFECTOR_SELECT  tool, 

SUBUSYSTEH.ID  ssid) ; 

u8_select_sen8or(  TASK.ID  tid, 

RESOURCE.SELECT  agent , 

SUBUSYSTEH.ID  ssid. 
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int  type) ; 

us_interp_run_plan(  SUBUSYSTEM_ID  ssid, 
int  type  , 
char  plan[128]); 

us_interp_halt_plan(  SUBUSYSTEM.ID  ssid) ; 
us_ptps_input_request(  SUBUSYSTEN.ID  ssblocker, 
SUBUSYSTEH.ID  ssenabler , 
int  type); 

us_ptps_output_enable(  SUBUSYSTEN.ID  ssblocker, 
SUBUSYSTEM.ID  ssenabler, 
int  type) ; 

us_tps_free8pace() ; 
us_tps_guardede() ; 
us_tps_constact() ; 
us_8upervisory_mode() ; 
us„8elect_feature(  FEATURE  surface, 
double  fx, 

fy. 

fz , 

double  fol , 
fo2, 
fo3) ; 

us.select .material ( MATERIAL.TYPE  m, 
double  naxx , 

maxy , 

maxz , 

double  minx, 

miny , 

minz , 

double  fol , 

fo2, 

fo3, 

double  strength, 
double  minf orce , 
double  maxforce); 

us_load_obstacle(  FEATURE  obstacle); 
us_load_pattem(  GEOHETRY.PATTERI  pattern)  ; 
us_tps_mark_event(  int  event); 

U8_ptps_enable(  int  enable) ; 
us_f raffleeork(  char  name  [128]); 
ns_symbolic_item(  char  neune  [128]); 
us_symbolic.item_attribute(  char  name  [128]  , 

char  attribute_name[128] , 
int  size, 
int  xdim, 
int  ydim, 

Representation.units.type  rep, 
Neasurement.units.type  units, 
generic_value_a  values); 

us_om_create(  int  type, 

char  name  [128]  , 
char  device [128], 

GEOMETRY  data) ; 
us_om_delete(  int  type, 

char  name  [128]); 
us_om_modify(  int  type, 

char  name  [128] , 
char  device [128], 

GEOMETRY  data) ; 
us_oc_calib(  int  type, 

char  name  [128] , 
char  device [128], 

GEOMETRY  data) ; 

us_oc_8et_attr(  char  name  [128]  , 

Modifier.t  modifier, 

Attribute.t  attributes. 
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int  size, 

Representation.units.type  rep, 
Neasurement_units_type  units, 
generic_value_a  value)  ; 
us_oc_get_attr(  char  name  [128] , 

Modifier.t  modifier. 
Attribute.!  attributes); 
us.ok.recordC  char  name  [128]); 
us_ok_create(  char  name  [128] , 

OBJECT  Ob) ; 

us_ok_delete(  char  name  [128]); 
us.ok.modify ( int  size, 

void  • data) ; 

us.ok.modify.attributeC  Attribute.!  attr, 
int  size, 
void  * data) ; 

us.ok.attr.query ( Attribute.!  attr)  ; 
us. registered. id(  char  name  [128]); 
us.ok.attr.response(  Attribute.!  attr, 
double  *values); 
us.trd.openC  char  name [128], 
int  type) ; 

us. trd. record ( char  njune[l28]); 
us.trd.positioningC  char  name [128], 

int  num. element ) ; 

us.trd.name.item(  char  naffle[128]); 
us. trd. delete. itemO  ; 
us.trd.set.joint.mode ( double  dof ) ; 
us.trd.set.Cartesian.mode(  double  dof); 
us. trd. modify ( char  name[128], 
int  num.element , 
double  edata) ; 

us. trd. add. element ( double  *data) ; 
us.sgd.error(  char  name  [128] , 
int  obj.idl, 
int  obj.id2, 
double  X, 

y. 

z) ; 

•endif 
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